気づけば卒業式シーズン。いかがお過ごしでしょうか。というかこっちの卒業式って3月の半ばなんですかね？（わかってない）

最近Emacs弄りの熱がまた上がってきたところですが、生成AIにコンセプトを伝えて作らせたものを紹介します。

できたもの

https://github.com/derui/projab

Project.el + Tab-bar というところで projab としました。一応ググってもそれっぽいのは出てこなかったので大丈夫だとは思います。

余談ですが、生成AIが提案した名前に workroom （後で出てきます）ってのがありましたが、もう全く同じ名前のpackageがありました。事前調査は重要ですね。

Project management系統なので、基本的に画面とかはありませんが、自分が欲しい以下の機能を兼ね備えたpackageがなかったので作成しました。

  • 標準パッケージにだけ依存する
    • Emacsの標準パッケージはすでにかなり充実していますので
    • 特に、visualにかかわらない部分については、大半が汎用性のある形でできてます
  • Bufferのリストだけ保存される
    • 意外と Window layoutも 復元しようとするケースがあるのですが、これは究極に複雑な系統になるのと、だいたいその辺キー一発なので切りたかったんです
  • 自動レストア機能 + Projectを開いたときだけ 復元
    • 大抵、projectを含めて全体を復元・・・ってやるのですが、それをやられると、長時間使ってると、次回起動時にとっても時間がかかるようになります
    • 実際、Nixをdirenvで有効にしているprojectがあったりすると、開くだけでLSPの起動やらなんやら含め、長時間待たされます
    • 私のsetupは、起動速度に重点を置いているので、ちょっと許容できなくなってきたという背景もあります

そんなことで、以下のことができるように、というコンセプトで作ってます。

  • project.el / tab-bar / desktop.el を利用する
  • project外のファイルも復元のリストに入れられる
  • 復元単位はproject = tab
  • Window/frameの復元は不要

とりあえず使える・・・って状態になるまで1,2時間くらいでした。ほぼほぼ利用する関数は自分でも把握していたので、reviewも早いですね。

自分が把握している範囲が広いほど、生成させるときも速い です。

他のpackageを利用しなかった理由

このsession管理というのは、Emacsの歴史上何度となく大きなトピックになってきた（と勝手に思ってます）ものであり、多数のpackageが存在しています。

  • Tabspaces
    • もともと利用していたもの。project.el + tab-barというのはほぼほぼ同一
    • ただし、 自動restoreは全体の復元が強制される ことと、Windowやtemporary bufferまで保存しようとすることで、復元するときに結構厄介な状態になったり、ということがあったのが、今回作った主な動機です
  • emacs-workroom
    • ほぼほぼ同じ動機。 project.el + desktop.el
    • ただ、tab-barのintegrationを作者がする気がない様子
  • perspective-el
    • この分野の有名どころ
    • より複雑な管理（merge/split）を可能としてます。elscreenとか書いてあるくらいなので、非常に歴史があるpackageでもあります
    • これも昔使ってました

つまり、個人的には 帯に短し襷に流し を地で行っている状態だった・・・というのが、ド新規でわざわざ作ろうと思った動機です。以前であれば、こうなると妥協して・・・ってのがありましたが、今はこれくらい（400〜500行程度）のElispであれば数分で作成できてしまうため、アイディアなりコンセプトの具現化は非常にやりやすいと思います。

やらないこと、を決める

このpackageでは、最初から以下はやらん、と決めていました。多分作らせようと思えばできるのですが、そもそもやる理由がないのと、コンセプトからブレるためです。

なんでもできそうな雰囲気の中で、やらないことを明示的に決める、ということの重要度は増してると思ってます。

3rd party packageへのデフォルト対応

readmeには書いてますが、consultへの対応とかは、packageの拡張としても作成できます。確かに生成AIを使えばすぐでしょう。が、あえて明示的にやらない、と記載しました。

これは、 その拡張の内容が万人が望むものではない ということと、単純にコピペで済むレベルなので、コピペして何なりいじってもらう、ってのがベターだと感じているからです。opinionatedなものは作成できますが、結局は どういう環境にしたいか？をpackage側は決められない ので。

1st partyの拡張もできるだけしないようにしてます。一部どうしようもない・・・ってなったため、内部実装に依存する変更をしてたりはしますが、3rd partyよりも変更に耐性はあると思ってます。多分。

Window layoutのrestore

大体のsession管理系統はこれをやろうとしてますが、これは最初からコンセプトとしてやらない、と決定してました。desktop.elがやる範囲以上は最初から無視してます。

EmacsのWindow管理は、柔軟すぎるが故に超絶難しいものになってます。また、昨今はside windowやIDE的な運用が多く、大抵分割するとしても2,3個がせいぜいです。side windowは表示される場所が決まってることが多いので、そもそも保存する動機が少ないですし、どんなに頑張っても10個とか分割されたものは大体使い物にならないと思ってます。

https://karthinks.com/software/emacs-window-management-almanac/

超長い記事ですが、包括的な理解ができる記事になってます。Emacsの深淵を覗きたい場合はどうぞ・・・。

そういうことで、単純に、最後に利用されていたファイルが表示されればそれでよくない？というところで、その複雑さと向き合うのはWindow管理のpackageがやるべきで、復元というところに責務を持たせない、という設計判断としてます。

ところで使い勝手は？

早速自分で使ってみる・・・というか自分以外に利用する想定はないのですが、だいぶ快調です。tab-barに諸々寄せることで、管理面が楽になるのは、 tabspaces を利用していた段階でわかっていました。公開する機能を

  • projectのopen/close
  • bufferの追加・削除
  • project内のbuffer list
  • save/restore

だけに絞っていることで、ソースの見通しとリファクタリングのやりやすさも向上してると思います。

興味があれば利用されても構いませんが、Licenceの通りNo warrantyとなってますので、desktop.elで保存していたのが吹き飛んだ！とかあっても責任は取れませんので、あしからず・・・。

環境であるEmacsの価値

ここ数年、VSCodeの台頭で息の根を止められた・・・だったりLLM first（個人的には、現状の仕組みを広義のAIと言いたくない気分）なEditorじゃないとオワコン、とか見ます。まあEmacs自体の利用者数は多分いい感じに減っていってるのは感じてます。

現職でも、少なくとも部（30人くらい）を見渡してもEmacsenは私一人になっちゃいました。切ない 😢

ただ、Vim含めて他のエディタはあくまで エディタ である、というところに対して、Emacsは OS という領域に足を突っ込んでいます。VSCode/Zedの上でメール管理する人はいないでしょうが、Emacsは普通にできますし、メンテナンスもされ続けてます。 SlackなどのIM Clientも、IRCの古から存在してます。

packageを作成する・・・というところが簡易になったことで、Emacsの強烈な柔軟性がまた価値になってくる・・・と思ってます。text propertyとか狂気を感じますよ。

とりあえずひっそりとEmacsを使い続けていく所存です。