TeraPad、サクラエディタ、秀丸。
振り返ってみれば、私にとってテキストエディタは、あくまで「ちょっとした道具」でした。メモを取ったり、出力されたログファイルを眺めたり。開発のメインステージにはいつもIDEがいて、Unreal Engineでの開発も、もちろんその中で完結していました。
それなのに、今の私はどうでしょう。
IDEを離れ、あまつさえNvimプラグインを自分で作りながら、あの頃の"ただのテキストエディタ"での開発環境に戻ろうとしています。
不思議なものです。
これは、そんな私の、テキストエディタを巡るちょっとした軌跡のポエムです
IDEライクなエディタと
話は、CodeWarriorで開発をしていた、ずいぶん昔に遡ります。
当時のIDEは、今思うと、そこまで賢くはありませんでした。私自身の開発スタイルが、アセンブリを多用する少し癖のあるものだったせいか、「もしかしたら、IDEじゃなくても良いのかもしれない」と、少しずつ思うようになっていきました。
気がつけば、開発のメインにテキストエディタを据えていました。
ただ、秀丸やサクラエディタではなく、MDI（複数のウィンドウをタブで管理できる）ベースで、プロジェクトのファイルツリーも表示してくれるような、IDEの面影を残したエディタでした。
（残念なことに、そのエディタの名前をど忘れしてしまって。こういう時、Google検索で年代を絞って探せたらいいのに、と思います）
Emacsという魔法と
テキストエディタでの開発を続けていたある日のことです。
隣の席の先輩が、まるで魔法のようにエディタを操っていました。
エディタ上でメールを読み、バグトラッカーをチェックし、そしてそのまま流れるようにコードを書き始めたのです。
「なんて格好良いんだろう」。
素直にそう思いました。
興奮気味に尋ねると、それは「Meadow」という、Emacsの一種だと教えてくれました。私が初めて"Linux系エディタ"という文化に触れた瞬間でした。
そして、若かった私は、とても素直にEmacsに挫折します。
どうしても、C-（コントロールキー）から始まる、あの独特なキーバインドに指が馴染んでくれなかったのです。
Vimという居場所と
そんな時、もう一つのエディタである「Vim」に出会いました。
「モード」という概念を持つVimは、テキスト編集という一点においては、Emacsよりもずっと特殊なエディタかもしれません。
それなのに、不思議とこちらは私に馴染んでくれました。
「困ったら、とりあえずEscapeキーを連打すればノーマルモードに戻れる」という、あの妙な安心感。
そして何より、Emacsでは複雑なキーの組み合わせだった操作が、Vimでは:wのように、まるで呪文（コマンド）を打ち込むスタイルだったこと。これを、当時の私は「なんだか格好良い」と感じてしまったのです。
それが、私がゆっくりとVim沼にハマっていったきっかけでした。
沼の底と
Vim沼に沈んでいた私は、あのEmacsの先輩の衝撃が忘れられませんでした。
「Vimですべてを完結させたい」。
そう夢見て、いろいろなプラグインを試しました。
でも、すぐに「あ、それはEmacsの世界の話だな」「Vimは非同期処理がちょっと……」といった壁にぶつかります。
それでも、Vimで動くTwitterクライアントが出たと聞けば、嬉々としてそれを使い、ただただ自己満足に浸っていました。
そんな日々が数年続いたある日。
私はふと、「エディタは、やっぱりエディタだな」という、とても穏やかな境地にたどり着きました。
スタンスが変わったのです。
「何でもかんでもVimでやる」のをやめて、「Vimでできることを、気持ちよくやる」へ。
もちろん、今でも楽しそうなプラグインが出たら、全力で試してみるスタンスは変わりませんが。
あれほど憧れた「VimをOSにする」という沼。その底にようやく足がついて、もがくのをやめた、ということなのかもしれません。
Vimというエディタそのものの沼は、きっと一生かかっても底は見えないのでしょうけれど。
今はそのほとりで、自分なりの快適な場所を探している。そんな感覚です。
ウィンドウ分割と、Uniteと
しばらく開発を続けていくと、ライブラリは少しずつ肥大化し、プロジェクトのファイル総数も増えていきました。
ctags での補完精度は下がり、そもそもタグの生成時間もひどいものになっていきました。アセンブリを書くこともほとんどなくなり、周りの開発者たちも、Visual Studioを代表とするIDEへと移っていきました。
しかし、私はVimを使い続けていました。
理由はただ一つ。クラスを書くとき、ヘッダーとソースを同時に見ながら編集できること。あるいは、複数のヘッダー定義を眺めながら作業できること。
この「ウィンドウ分割」機能が、マウス操作なしで扱える快適さが、私には便利すぎたのです。
ただ、肥大化するプロジェクトでは、ファイルブラウザ機能も必須でした。
あちこちに散らばったクラスを行き来するには、ツリービュー表示のプラグインが欠かせませんでした。
そんな時、Unite や CtrlP が現れました。
どんなにファイルが散らばっていても、目的のファイル名はある程度予測がつきますし、#include していれば名前はすぐにわかります。
Emacsに挫折し、Vimの世界しか知らなかった私にとって、これは本当にブレイクスルーでした。
（あとでshougoさんの記事を読み、Emacsには anything という形で存在していたことを知るのですが）
この出会いによって、私はUEに出会うまでの間、ファイルブラウザ系のプラグインをたまに使うことはあっても、常用することはなくなりました。
Omnisharpと、LSPと
Unityを使ったアプリゲームのお手伝いを始めた頃、「C#もVimで書けないか？」と思い立ちました。
当時の私は、ゲームコードはVim、C#を使ったコードは完全にIDE、と使い分けていました。理由は簡単です。補完が効かない、定義はDLLの中、XAMLのような複雑なUIを人が一から書くのはしんどすぎる。これに尽きます。
ですが、時期が良かったのでしょう。
ちょうど「C#をVimで」と調べていた頃に、Omnisharp が登場しました。
（その魔法のような機能は、のちに LSP という標準規格になり、今に至ります）
華麗な補完機能をVimで手に入れた私は、そのUnityプロジェクトの最後まで、デバッグ以外でIDEを触ることはありませんでした。
Unreal Engineと
そんな中、次のプロジェクトでUEに出会います。
その頃にはLSPも標準規格として広まっており、「UEでもすんなり使えるだろう」と軽く考えていました。
ですが、現実は全然そんなことはなく。
最初の頃は、Windows環境下で compile_commands.json すらうまく作れず、大きめの .clangd ファイルを「おまじない」のように作っては、騙し騙しLSPを有効にしていました。
Vimを起動はするものの、一度IDEを触ってしまったら、もうその日はVimに戻ってこない。そんな日々を送っていました。
UE5と、今と
UE5がリリースされ、バージョンが上がるごとに compile_commands.json の出力が安定してきました。
「今こそ、もう一度」。
あの頃のように、「コードはVim、デバッグはIDE」というスタイルに戻る時が来たと感じ、そのためのプラグイン開発を始めたのが、今です。
これからと、nvimと
多分、今後も私はNvimを使い続けると思います。
半ば呪縛のようにも感じますが、手が覚えてしまったので仕方がありません。
そして、もしUE5以外のエンジンを使う時、それがC++で作られているなら、私はきっと、まず compile_commands.json を作ることから始めるでしょう。
もしかしたら、今作っているものと似たようなプラグイン群を、また作っているかもしれません。
守秘義務の多い業界です。もしそれがクローズドなエンジンだったら、どこにも公開されない、私だけのプラグイン達がひっそりと作られることでしょう。
（VimからNvimへの移行話は、また別の機会に）
では、単なるポエムでした。