Emacsのすべてをサービス化！究極の統合環境構築術

Emacsを使っていると、もはや「すべてがサービスである」という感覚に陥ります。編集ツールという枠を超え、システム全体をEmacsというインターフェースで制御するこの強力なパラダイムについて、皆さんはどう思いますか？

ここ2年ほどEmacsを使ってるよ。最初はorg-modeを試したくて使い始めたんだけど、とにかくカスタマイズ性が抜群だからそのまま居着いちゃった。

キャリアの中で一番の転機だったのは、Emacsを使い込んで「Emacsはオペレーティングシステムである」という意味を、ただのジョークじゃなくて心から納得できた時かな。

「EmacsはOSだ」というのはよく言われるけど、実際には違う。ただ、OSカーネルの上でアプリケーションやユーティリティを統合する能力があるからそう見なされるんだよね。結局のところ、Lispマシンやその派生形がメインストリームにならなかったせいだと思う。「Symbolics Lisp Machine demo」https://www.youtube.com/watch?v=o4-YnLpLgtk 「Emacs and Lisp」https://funcall.blogspot.com/2025/04/emacs-and-lisp.html LucidがXEmacsとしてEmacsをフォークしてLSPの先駆けみたいなことをやったけど、今ではそのほとんどの機能がEmacs本体に統合されてるよ。https://dreamsongs.com/Cadillac.html 「Lucid Energize Demo」https://www.youtube.com/watch?v=pQQTScuApWk

正確にはOSじゃなくてシェルだよね。ただ「シェル」っていう概念自体がちゃんと理解されてない気がする。

最近これを見つけたんだけど、Emacsを普段使わない人にとって短くていい入門動画だよ：https://www.youtube.com/watch?v=mJZDmO5yOxE

結局「クライアント」「サーバー」「リクエスト」の定義を広義にとらえれば、何でもクライアント/サーバー構造に押し込めるって証明してるようなもんだね。Emacsも「LISP関数が一つだけ、かつそれを上手くやる」ならUnix哲学に従っている、なんて無理やりこじつけようとする人がいたのを思い出したよ。そんな定義をして何が得られるのか分からないけどね。EmacsがLISPマシンの思想に基づいているってことはみんな同意するだろうし、そこから先は何だってできる。CLIツールとの連携は素晴らしいし、それをクライアント/サーバーと呼びたければ呼べばいいけど、定義したところでメリットはあるのかね。現実としてEmacsは何十年もかけて色々な流行を取り込んできた。中にはCEDETみたいなセマンティック解析エンジンも埋もれてるけど、今はLSPが主流だし、最近ではAIエージェントのフロントエンドとしてもEmacsはかなり優秀だよ。

もう25年以上Emacsを使ってる。でも去年転職したら、Emacsが完璧に機能するようなタスクですら使わせてもらえなくなったんだ。チーム全員で同じツールを使うべきっていう主張で、まあ理屈は分かるんだけどさ。残念ながら、全員をEmacsに乗り換えさせるほどの説得力は自分にはなかったよ。今はタスクごとに専用ツールを使い分けてるけど、Emacsを使うより効率は悪いし、慣れないUIとキー操作を覚えるのに苦労してる。

だいぶ前に知ったんだけど、Emacsってテキストエディタが組み込まれたプログラミング環境に近いんだよね。Smalltalkのイメージみたいな感じ。そう考えると結構面白いよ。

Emacs自体はクライアントとしてもサーバーとしても動くよ。サーバーとして起動するには emacs --daemon を使って、あとは emacsclient で接続するだけ。ターミナルからでもGUIからでも、同じサーバーに接続して同じファイルやバッファを操作できる。ただ、残念ながらローカルでしか動かないんだよね。ssh経由でソケットを転送してみたけど、上手くいかなかった。

忘れがちだけど、「すべてはサービス」という考え方はLSPよりずっと前からあるよね。Emacsはずっと前からサブプロセスやRPC風の連携、TRAMPやGUD、REPL統合なんかを実現してきたんだ。LSPは重要なインターフェースを標準化したけど、それがアーキテクチャの始まりじゃないんだよね。