テキストエディタをEmacsからVSCodeに切り替えました。僕は、EmacsマニアでもなければEmacs LOVEでもない、単に長期間普通に使ってきたユーザーです。なので、Emacsを捨てることに心情的な抵抗はないです。が、長い期間で身体に染み付いたEmacs脊髄反射はなかなかに抜けません。無意識の指の動きに予想外の反応をされると、舌打ちをしたくなります -- 「チッ、こいつぅ」。
内容：
- ウインドウ・アプリケーションとコンソール・アプリケーション
- ダイアログとツーストロークキー
- IMEを監視・制御できないこと
- 万能強烈キャンセル C-g はもはや無い
- dired生活から離れて
- ではどうする
ウインドウ・アプリケーションとコンソール・アプリケーション
VSCodeは、Chromium／Electron上に実装されています。これにより、クロスプラットフォーム性を確保しています。UIに関しては、各OSに付属のウィンドウシステムを使います。よって、各OSのウィンドウシステムのお作法は守っているわけで、現代の標準的なウインドウ・アプリケーションです。生まれながらにしてウインドウ・アプリケーションです。
それに対して、太古から存在するEmacsは、もともとは“文字ターミナル”で動いていたものです -- ターミナルとコンソールは昔は違ったのだけど、今どきは「コンソール」のほうが通じるので、コンソール・アプリケーションと言いましょう。コンソール・アプリケーションであるEmacsは、ウィンドウシステムのお作法を守っているわけではなくて、ウィンドウシステムからもらった一枚のウインドウ内でコンソールをエミュレーションしています。
VSCodeとEmacsでは出自が違う、いや、むしろ世代が違うのです。少年と爺さんの違いです。人間の爺さんである僕の偏見としては、テキスト編集には、コンソールの表示法・操作感のほうが向いていると思います。現在VSCodeに感じる不満のひとつは、ウインドウが持つ情報が多すぎるのです。表示されてるだけなら無視できるのですが、ちょっとしたミスタッチで、フォーカスがメニューバーやサイドバーに飛ぶのです。ミスの責任は自分ですが、「チッ、こいつぅ」となります。
Emacsの場合は、バッファ（テキスト編集領域）だけしかないので、フォーカスの飛びようがありません。バッファ切り替えコマンドは、ツーストロークキーなので、滅多なことでは誤操作しません。カーソル位置を睨んでキーを叩く作業を邪魔する要因は何もありません。
ダイアログとツーストロークキー
例えば文字列検索をするとき、文字列入力用のダイアログボックスが出るのが常識的なUIです。VSCodeも、もちろんそうなっています。僕が今使っているEmacs Friendly Keymapでは、ダイアログボックスのキーバインドまで変更が及ばず、検索文字列入力時は標準キーバインド（僕にとっては使いにくい）です。
VSCodeレベルでの対処方法が分からないので、AutoHotKeyで（「プログラミング言語としての AutoHotKey」参照）グローバルにホットキー設定をしました*1。次のようです（Ctrlキーとの同時押下を「C-」と表記します。特殊キーはキー名で表します）。
| 入力されるキー | 変換後のキー |
|---|---|
| C-m | Enter |
| C-[ | Esc |
| C-h | Backspace |
| C-d | Delete |
| C-f | Right |
| C-b | Left |
| C-a | Home |
| C-e | End |
| C-n | Down |
| C-p | Up |
AutoHotKeyのグローバル設定はアプリケーションによらずに効くので、ダイアログボックスでも有効です（Emacs Friendly Keymapの目ぼしい設定は意味なくなってます）。これで快適になったように思えました。が、ツーストロークキーの2ストローク目までAutoHotKeyが効いてしまいます。例えば、C-x C-f のツーストロークで起動されるfind-file（ファイルを開く）コマンドが動きません。それは当たり前； C-x C-f が C-x Right になってVSCodeに届くのですから。
AutoHotKeyがC-xを捉えたとき、状態遷移して、次のストロークは無変換スルーさせるように設定できるかも知れませんが、調べる／試す気力が湧きません。VSCodeのツーストロークキーの2ストローク目を無修飾キーに変更する対処はあります。が、これはこれで問題があるのです（次節へ）。
IMEを監視・制御できないこと
「VSCodeのEmacsキーバインド // IME状態がわからない」で、VSCodeがIME監視を出来ないことから、日本語入力の効率が落ちることを述べました。VSCodeは、IMEに対して何も出来ないのです。入力時IME状態が分からない以外の問題も生じます。
例えば、ツーストロークキー C-x b〈switch-to-buffer〉を実行しようと、C-x を押します。次にbを押すとき IME On だと、bがIMEに渡ってしまいVSCodeに届きません。Emacsでは、コマンドとなるマルチストロークの1ストローク目が来た段階で IME Off されます。その後のストロークは直接Emacsに届きます。また、明らかに英数字しか入力しない状況では自動的に IME Off されます。Emacs以外でも、このような挙動は普通だと思います。
この普通の挙動がVSCodeは出来ないのですよ。VSCodeの責任というより、Chromium／ElectronがIMEを考慮してないのが問題かも知れません。将来的には改善されるとは思いますが、現状は辛い。
万能強烈キャンセル C-g はもはや無い
Emacsを使っているときの“安心感”の理由として、オートセーブやアンドゥと共に、C-g によるキャンセル機能の存在が大きいと思います。どんな場合でも、C-g を押せば編集トップレベルに戻れます。
Emacsにおける C-g〈keybord-quit〉は、内部では場合分けした複雑な操作ですが、ユーザーからは一様なセマンティクス「とにかくやめる」に見えます。僕の記憶では、適切なタイミングでフラグのチェックをして、C言語のlongjmp関数でトップレベルループに戻っていたと思います。けっこうエグいことやってます。
現代のアプリケーションでは、longjmp のような野蛮な方法はまず採用されない（または、そもそも不可能）でしょう。現代の標準的アプリケーションであるVSCodeでは、部分的なキャンセルは実装できても、万能強烈なキャンセルは無理なような気がします。
dired生活から離れて
VSCodeはコードエディタなので、プログラムコードのまとまりとしての“プロジェクト”の概念を持っています。プロジェクトは原則的にはファイルシステムのディレクトリに対応します。したがって、カレントディレクトリの変更はプロジェクトの切り替えになります。複数のディレクトリにまたがるプロジェクトも作れますが、僕の希望は、異なる目的の複数のディレクトリをこまめに渡り歩きながら編集することなので、ちょっと違う。
複数のディレクトリをこまめに渡り歩く行動習慣においては、dired（Emacsのファイルマネージャー）は重要な位置を占めます。僕は、diredを中心とした生活をしていたと言えます。今のところ、Emacs diredに匹敵するVSCode拡張機能は見つかりません。現状では、「diredバッファ1枚 ＝ VSCodeインスタンス1個」と考えて、ディレクトリごとにVSCodeのインスタンスを立ち上げています。これがベストな方法とも思えないのですが‥‥
ではどうする
「そんなこと言うならEmacsに戻れや」とか「EmacsとVSCodeの二本使いでいけば」とかのご意見はごもっともです。が、VSCode拡張機能で使いたいものがあったり、二種のエディタを常用するのは負担に感じたりで、やっぱりVSCodeを使おうとは思っています。この記事で、Emacsのメリットのように取り上げた機能（独自ダイアログ〈ミニバッファ〉、C-g キャンセル）も、時代遅れで消滅すべき機能だ、とも言えます。Emacs脊髄反射も、時間がたてば抜けていくでしょう、たぶん。
*1:グローバルにホットキーを設定すると、全てのアプリケーションに影響するので、トラブルを引き起こすリスクがあります。アプリケーションごとに分けるのが望ましいでしょうが、「めんどうだ、エイッ」とやってしまいました。
