さようならVS code, Zed

ふとしたことで純Rust製の高速エディタが開発中 by zed.devというのを見て早速登録してみたもののなんの音沙汰もなし（知った時点でHacker newsで紹介されてから既に数ヶ月）。同じようなタイミングでReddit経由でhelixというエディタを知った。コンソール内で動くS+V形式のvi系エディタということだが（名前だけは知っていた）基になったKakouneともども色々設計方針を読み、なんか面白そうなので使っていみたら大変気に入ってしまった。

いいところ：

multi selectionが基本機能。実はまだKakouneのデモにある機能が再現できないのだけど、selectionから複数のselectionを作り、それから必要なものだけを選択し、編集したり、必要なものだけを削除して別の場所にまとめて貼り付けたりできる。これはつまり関数型プログラミングパラダイムのiter, map, filter, collectそのものじゃないか。これはテキストエディターに来るとは思っていなかった、乗り換える価値のある「新しさ」ではなかろうか。
LTSが基本機能。Rustに関しては本体とRust-analyzer以外不要。保存するだけでclippyのメッセージが埋め込まれる。
構文解析器tree-sitterが標準組み込みなので、引数単位、式単位、文単位などでの移動ができる。 Surround系機能が時代遅れに感じる。 SchemeやCommon Lispを対象にGnu Emacsが提供していたsexp系の機能が今の時代に復活してきたような感慨深いものがある。
レジスタ指定貼り付け時など、所々でKakouneと同様に情報ボックスが表示される。これは親切。
挿入モードに入った後の編集機能のキーバインディングがEmacs。なので挿入モードに入った後はEmacsみたいな感じで編集できる。つまりほとんどの時間は入力モードで時々移動と選択が便利。これはEmacsを挿入に特化したエディタというvi派の主張に乗っかっていうなら、Helixは移動編集用モードが追加されたEmacsとも言える。これまでお気に入りだったEmacs w/ evil modeからさらにpost modernな感じで融合したしたような印象。ほぼ乗り換えてしまった。
"anchor"という言葉がマニュアルにできてきた。これはEmacsで言うところのマーカーではないか。 vi系エディタでのカーソルの基本コンセプトがどうしても身に付かないところがあったのだが、 cursorとmarkerの2種類の(文字と文字との間に位置する)場所指定子から構成されるリージョン(helixでいうところのsection)があって、それが;でキャンセル(shrink)、Alt-;で場所指定子の入れ替えができるとなるともはやEmacsと変わるところがない。また挿入が単なるリージョンの置き換えに加え、リージョンの直前、直後への挿入が用意されていると考えれば拡張された機能として納得いくものがある。 (そう考えるとnormal modeのカーソルはblockではなく、広がりをイメージさせるunderlineにしたいところなのだが、どうもしっくりこないので固執するのはやめた。)

というわけで、gnus, magit, diredなどEmacsが得意な非ファイル系の操作以外の、つまり基本編集に関してはとうとうhelixの方が便利かもというところまで来てしまいました。

色々

構文を認識していない

最近grammarの取り込みが選択的になったせいか、このようなことが起きるようになった。 README.mdには以下のように書いてある。

cargo install --path helix-term
hx --grammar fetch
hx --grammar build

しかし少なくともmacOSでは、

rm -fr runtime/grammar

がインストールの前に必要だった。これはどうもデフォルトのHELIX_RUNTIMEがCARGO_HOMEから構成されていたみたい。 ~/.config/helix/runtime を作るところから始めれば問題ないかも。ということでissueを立てるような話ではなかった。

なぜかCtrl-{h,l,j,k}が空いている

もったいない。tree-sitterを使った構文単位の移動がAlt-{h,l,j,k}に割り当てられているのだけど、 AltはmacOSだと押しにくいOptionに割り当てないといけない。なぜかCtrlをprefixにしたキーシークエンスが開いていることに気づいたので、そちらに割り当て直したら非常に便利になった。Rustで式単位、文単位での削除移動がセクションの始まりと終わりを気にせずできるようになった。

ということで現在、~/.config/helix/config.tomlでのnormal modeの設定はこんな感じ

[keys.normal]
"C-h" = "select_prev_sibling"
"C-l" = "select_next_sibling"
"C-j" = "shrink_selection"
"C-k" = "expand_selection"
"D" = "delete_char_backward"
"H" = "move_prev_word_end"
"^" = "goto_line_start"
"$" = "goto_line_end"

move_prev_word_endはせっかく定義されているのにバインドされていないので、対称性を担保するためにも修飾されたhに割り当てた。
Dは本当はC-hであるべきではあると思うのだが（実際全然慣れないのだが）構文木移動系に取られてしまったので仕方なく。
^|$は設定するよりgh|glに慣れるべきなんだろうが、そこまで自分を追い込まなくてもいいだろう。正規表現の長い歴史に敬意を払って、または怠惰な自分のために残した。

Solarized系テーマでは対応する括弧とカーソルとの見分けがつかない

(2022-03-25) ちょっと修正したバージョンが取り込まれました。

対応する括弧のための表示修飾とカーソルのそのもののそれが同じというのはすごく嫌。カーソルの位置とその表現がvi系と違っているため括弧とカーソルがずれているEmacsや、対応する括弧は同じ表示修飾を使っているけどもカーソルの表現がその上に乗っているVScodeではこうならない。しょうがないのでパッチを当てた（正確には別名を割り当てた）。

diff --git a/runtime/themes/solarized_dark.toml b/runtime/themes/solarized_dark.toml
index e3d587d4..dd2013e2 100644
--- a/runtime/themes/solarized_dark.toml
+++ b/runtime/themes/solarized_dark.toml
@@ -81,7 +81,7 @@
 "ui.cursor" = {fg = "base02", bg = "cyan"}
 "ui.cursor.insert" = {fg = "base03", bg = "base3"}
 # 当前光标匹配的标点符号
-"ui.cursor.match" = {modifiers = ["reversed"]}
+"ui.cursor.match" = { fg = "base03", bg = "base00" }
 
 "warning" =  { fg = "orange", modifiers= ["bold", "underlined"] }
 "error" = { fg = "red", modifiers= ["bold", "underlined"] }
diff --git a/runtime/themes/solarized_light.toml b/runtime/themes/solarized_light.toml
index 3191add3..9c820294 100644
--- a/runtime/themes/solarized_light.toml
+++ b/runtime/themes/solarized_light.toml
@@ -81,7 +81,7 @@
 "ui.cursor" = {fg = "base02", bg = "cyan"}
 "ui.cursor.insert" = {fg = "base03", bg = "base3"}
 # 当前光标匹配的标点符号
-"ui.cursor.match" = {modifiers = ["reversed"]}
+"ui.cursor.match" = { fg = "base02", bg = "light-gray" }
 
 "warning" =  { fg = "orange", modifiers= ["bold", "underlined"] }
 "error" = { fg = "red", modifiers= ["bold", "underlined"] }

ここだけの話

vi系は移動が便利だとは思わない。選択が便利なのでは。

Published at 2022-03-15 Last updated 2021-03-21