LLM時代にこそEmacsが良いのかもしれない

LLM時代のテキストエディタに求めるもの

LLMの発展で直接コードを書く機会が大きく減った

対してドキュメントや仕様書を書く機会が大きく増えた

複数のcoding agentを並列して動かすことが当たり前になった

vibe-kanbanやsymphony等のagent orchestratorの登場

これからテキストエディタに求められるもの

快適な文章執筆環境

ドキュメントの読み書きが主軸となっていく以上、文章を快適に読み書きできる必要がある

表現力のあるplain textフォーマットがある

markdownは悪くないが、限界がある

plain textによるドキュメント作成が開発の主軸となる以上、そのplain textの表現力が仕様の表現力の上限になる

HTMLは人間の読み書きにはあまり向かない

Markdown以上HTML以下の表現力を持つテキスト形式が欲しい

プレーンテキストは常に勝つ

LLMを扱うにあたり、一定の再現性が欲しい

プロンプトと出力結果を一つのテキストで保存できると便利

快適なgit操作

coding agentを並列で実行するとcoding agentがバカスコcommitを積んでくる

大量に積まれたcommitを高速に裁けるよう、高速に操作できるgit clientが欲しい

ついでにGitHubの操作も行えると嬉しい

git操作自体も全てcoding agentが行うようになっているため、いずれ不要になるかもしれない

それでも操作できるに越したことはない

カスタマイズ性

coding agentによってテキストエディタの設定を自然言語で行えるようになった

これにより、チューリング完全な言語で設定が行えるテキストエディタの優位性が高まったと感じている

一般的なテキストエディタは設定の読み込みを起動時か任意のタイミングで行う

coding agentによる高頻度の設定更新に向いていない

高速で起動するようチューニングした場合はまだ対応できるとは感じている

Emacsはそれ自体が一つの言語処理系(Emacs Lisp)となっている

一般的なテキストエディタはテキストエディタと拡張言語が主-従の関係にある

Emacsの場合はそれが逆転しており従-主の関係にある

そのため、Emacsは他のテキストエディタと比較して非常に高いカスタマイズ性を備えている

また、Emacsは通常daemonとして動かすため、行った変更を再起動せず即時反映できる

emacsclientというEmacs daemonに接続するコマンドを用いると、Emacs daemon上で直接Lispを評価できる

従来のテキストエディタではmcpが必要な操作が、標準のコマンドで可能となっている

verb.el

Emacsで動くHTTP Client

誤解を恐れずに言えばplain textで動くpostmanみたいなもの

バッファ上にリクエスト情報を記載し、それを元にリクエストを発行する

リクエストの情報がテキストに残るため、雑にE2Eを試したりAPIを調べる際に便利

ddskk

SKKの(恐らく)最初の実装

SKK(Simple Kana Kanji)

非常にシンプルなかな漢字変換システム

一般的なIMEとは異なり、形態素解析による境界の判定を行わない

そのためユーザーが境界を明示する必要があるが、その特性ゆえ意図しない変換が発生しない

通常はShiftで境界を明示する

HonnjituhaSeitennnari(本日は晴天なり)

詳細はニコニコ大百科が詳しい

実装がシンプルという特性上、テキストエディタ上で実装が可能

Vimではeskk.vim、skkeleton.vimが実装として存在する

skkeleton.vimはTypeScript(Deno)で実装されており、よりモダンな実装となっている

必須ではないが、AZIKというローマ字を拡張した変換テーブルを併用することが多い

AZIKを用いるとより短いキーストロークで日本語入力が可能になる

これもまた必須ではないが、変換を明示する際にSticky ShiftやSandSを用いている人が多い

前者は特定のキーを押下した後に任意のキーを入力するとShiftとして扱われる

後者はSpaceと任意のキーを同時押しした際にShiftとして扱われる

僕はSKKによる入力時にAZIKとSticy Shiftを併用している

gptel

EmacsのLLMクライアント

様々なLLM Providerやモデルが使用できる

EmacsからLLMを扱う際の基盤となるパッケージ

単体でも有用で、別途mcp拡張を入れることでmcpも扱える

system promptなど、設定できる箇所も多い

agent-shell

ACP経由でコーディングエージェントをEmacsから実行できる

EmacsのterminalはTUIを相性が良くない

SKKを併用している場合、terminal bufferからSKKによる日本語入力ができない

agent-shellはcomit-modeをベースに構築されているため、SKKによる入力が可能

opencodeとpi-coding-agentを動かすのに使っている

magit

Emacsで動くGitクライアント

Emacsのkiller application

Vimにも類似プラグインが存在するが、機能を100%サポートしている訳ではない

これのためにEmacsを使っているという人もいる

git cliのコマンドやオプションをある程度知っている想定のツール

オプション指定や挙動がgit cliベースなので驚きが少ない

最悪操作が分からなくなったらgit cliで引き続きgit操作が可能なため、復帰しやすい

hankのstagingとsquashのcommit選択を行う体験がかなり良い。これはcliでは実現できない

magit拡張のforgeを用いるとGitHubの操作も可能

magitで作成したcommitをpushし、PRを作成するまでを一貫してEmacsで行える

慣れるとかなりのスピードでPRを作成できる

org-mode

Emacsのkiller application(2)

Vimにも類似プラグインが存在するが、機能を100%サポートしている訳ではない(2)

これのためにEmacsを使っているという人もいる(2)

多種多様なファイルへと変換できる

変換にはもっぱらEmacs本体のexport機能を使う

pandocを用いるとより多くの種類のファイルへ変換できる

以下のようなユースケースがある

orgからmarkdownへ変換してhugoでSSG

orgから直接ドキュメントサイトを生成

基本はMarkdownのような軽量マークアップだが、拡張性が非常に高い

コード実行(babel)

ナレッジ構築(roam)

表計算(org-table)

TODO

ポモドーロタイマー

勤怠管理

大抵のことは実現できる

babel

orgのcode block上でプログラムを実行できる

Jupyter NoteBookの様な機能が「任意の実行可能なテキスト形式」に適用できるものと考えてほしい

実行内容と実行結果が一つのファイルにまとまるため、記録性とインタラクティブ性に優れる

例えば以下のようなテキスト形式を実行できる

verb.el: ob-verb

verbに組み込まれている

gptel: ob-gptel

agent-shell: ob-agent-shell

roam

文章を連動させるメモを作成できる

roamresearchというアプリが元ネタらしい

扱える領域としてはObsidianに近い

実はそこまで使えていないので、使いこなせるようにしていきたい

今後欲しいもの

agent-shellのもう一つ上にレイヤーを加えorchestrationを抽象化したい

GitHub連携するならSymphonyみたく別アプリケーションを作成し、EmacsからAPIでアクセスする形態が良いのかもしれない

最近Gleamでagent orchestratorの基盤を実装しているので、Emacsとの連携も視野に入れて作ってみたいところ

roamを使っていない理由にObsidianとの連携が出来ていない点がある

上手いこと連携させる手立てを考えたい

markdown to orgの自動変換機構とか

roamの内容を元にgptelでブレストするとか