- リモートサーバー開発用エディタとして Helixを選んだ 理由は、Vim/Neovimのように数十個のプラグインをインストールしなくても使え、サプライチェーン攻撃のリスクを減らせるため
- tmux連携設定 により、Helixで不足しているファイルエクスプローラーとGit TUI機能を補い、
yazi ファイルマネージャーや lazygit などをポップアップで実行できるように構成
- Vimスタイルのキーバインディング を移植し、行選択、カーソル移動、テキスト削除などの操作がVimと似たように動作するよう設定し、
ESC でマルチカーソルを初期化するよう変更
- ステータスライン(statusline) にGitブランチ、エンコーディング、位置などの情報を追加して生産性を向上
- Tree-sitterインジェクションを活用して Python/Go内のSQLクエリ、Markdownのコードブロックなどをシンタックスハイライトし、可読性を改善
- LSP、自動保存、カラーモードなどの高度な設定 を活用して作業の生産性を高め、細かくカスタマイズ
Helixを選んだ背景
- 最近の サプライチェーン攻撃の増加 とプラグイン依存の問題により、Vim/Neovimの代わりにHelixをリモートサーバー開発用エディタとして採用
- Neovimの数十個のプラグインがなくても 基本機能だけで使える 点が主な利点
- Helixへ移行してから、慣れ親しんだ Neovimの体験 をできる限り再現するために 設定のカスタマイズ作業 を進めた
- これを共有して、他のユーザーの時間節約を目指す
Tmux設定
- ターミナルマルチプレクサとしてTmuxを使っており、ファイルマネージャーとGit TUIの不在 を解決するためにカスタムキーバインディングを追加
- Helixはファイルエクスプローラーでのファイル編集をサポートしていないため、複数ファイルをすばやく移動するときに不便があった
- Tmux設定ファイルに次のバインディングを追加
prefix - y: Yaziファイルマネージャー をポップアップウィンドウで実行（画面の95%サイズ）prefix - g: Lazygit をポップアップウィンドウで実行prefix - e: Tmux出力履歴 をHelixエディタで開き、検索とコピー作業を実行
- デフォルトのprefixは
Ctrl + b だが、Ctrl + \ に変更して使用中
- ターミナル出力の作業に便利で、特に ClickHouseクライアント の出力（CSV/JSON）をSlackへコピーするときに活用
- ファイルへ出力する代わりに直接コピーできるため、作業手順を削減
- マウスでも可能だが、Tmuxバッファのスクロールが不便なので、エディタで処理する方が効率的
- YaziとLazygitは通常 Helixエディタの上にオーバーレイ として表示される
Vimキーバインディングの移植
- Helixのキーバインディングには慣れたが、それでも一部の Vimバインディングを移植 して使っている
- Selectモードのバインディング
0: 行頭へ移動$: 行末へ移動^: 最初の空白でない文字へ移動G: ファイル末尾へ移動D: 行末まで選択して削除し、ノーマルモードへ切り替えk/j: 上/下の行全体を選択（Helixのデフォルト動作は部分選択で不便）
- Normalモードのバインディング
D: カーソル右側のテキストをすべて削除（Helixはキー入力が多すぎるため移植）V: Selectモードへ切り替えて行全体を選択ESC: マルチカーソルのリセット （Helixのデフォルトはコンマで不便）
- Helixのビジュアルモードにおける行選択の方式が好みに合わないため、Vimスタイルに変更
改善したステータスバー
- デフォルトのステータスバーには 現在のGitブランチ のような重要情報が不足している
- ステータスバー設定の構成
- 左: モード、スピナー、バージョン管理、ファイル名、読み取り専用表示、変更表示
- 中央: 空
- 右: 診断、ワークスペース診断、位置、総行数、位置の割合、ファイルエンコーディング、改行形式、ファイルタイプ、レジスタ、選択数
- 区切り文字:
│ 文字を使用
- 作業状況をひと目で把握 できる
便利なキーバインディング
- カスタムキーバインディングによって 作業効率が大幅に向上 し、見つけるまでに時間がかかった
- 最も便利な機能: ファイル再読み込み、ソフトラップ切り替え、Git undo、Git blame、Git diff
- カスタムバインディング一覧
space - e - w: 現在のバッファをファイルとして保存space - e - c: 現在のバッファを閉じるspace - e - x: 他のバッファをすべて閉じる（数十個のバッファが開いているときに便利）space - e - l: インレイ型ヒントの切り替え （便利だが常時表示するとノイズが多い）+ - f: 現在のファイルをフォーマット+ - w: 空白文字のレンダリング （文書内の見えない文字を確認する用途）+ - W: 空白文字のレンダリングを無効化space - f - .: ファイルピッカーで Git無視ファイルの表示/非表示 を切り替えspace - f - r: すべてのファイルを再読み込み （Helixは自動再読み込みをサポートしていないため非常に便利で、外部変更やコミット後のgutter更新用）space - f - x: 現在カーソル位置の Git変更をundospace - f - w: 現在行の Git blameを表示space - f - d: Git diffを表示
エディタ設定
- 6か月使った後で、ターミナルタブ切り替え時の自動保存 機能があることを発見
- Helixの一部の新機能は デフォルトで無効 になっており、既存ユーザーが予期しない変更を経験しないよう配慮されている
- 各オプションを自分で確認してはじめて新機能を見つけられる
- 主な設定オプション
line-number = "relative": 相対行番号を表示rulers = [120]: 視覚的な縦ルーラー を設定（自動フォーマットなしで最大行長を制限するときに便利）true-color = true: トゥルーカラーを強制サポートcompletion-replace = true: 自動補完が単語全体を置き換えるtrim-trailing-whitespace = true: 行末の空白を削除color-modes = true: モード表示を色で区別rainbow-brackets = true: ネストした括弧に異なる色を使用 （新機能で、まだ正式リリース前）editor.file-picker.hidden = false: ファイルピッカーに隠しファイル(dot files)を表示editor.indent-guides.render = true: 視覚的なインデントガイド を追加editor.inline-diagnostics.cursor-line = "warning": 診断表示を改善 （スクリーンショット参照）editor.auto-save.focus-lost = true: フォーカスを失ったときに自動保存 （ターミナルのサポートが必要）editor.auto-save.after-delay.enable = true: 指定した 遅延時間後に自動保存 （300秒に設定）
LSP調整
- すべての言語に対して harper-ls LSPを追加 し、コメント内の文法エラーをハイライト表示
カスタムTree-sitterインジェクション
- Helixは カスタムTree-sitterインジェクションの指定 を許可しており、1つの言語の中で別の言語をハイライトできる
- 使用例
- PythonとGo内のSQLクエリ のシンタックスハイライト
- Markdownの YAML front matterとコードブロック のハイライト
- HTMLスニペットのハイライトにも活用可能
- GitHubに 設定ファイルをアップロード して、カスタムインジェクションと設定を共有
- Helixは プラグイン最小化、セキュリティ、直感的なカスタマイズ という長所が際立つ次世代ターミナルエディタ
2件のコメント
20年間Vimを使ってきた開発者による、VimからHelixへ移行した感想
Hacker Newsのコメント
最近、エディタ設定を組み直している。20年間 Emacs、15年間 Vim を併用していて、どちらか一方に決められない。目標は、エンタープライズ級の Python ソフトウェア開発にすぐ使える完成度の設定を、どれだけ素早く作れるかを見ること。今回は特に、サードパーティ拡張への依存をできるだけ減らし、本当に必要な機能だけ残せるかを試している。今の自分の Neovim 設定はこれまで使った中で最高だと思うが、予想以上に多くのプラグインを使うことになった。Emacs のほうはまだ初期段階だが、30 以降ではサードパーティプラグインの必要性が大きく減るほど進化しているのが興味深い。以前は
lsp-modeを使っていたが、今は Eglot で満足している。completion preview mode も corfu を完全に置き換えるわけではないが、かなり良いところまで来ている。自分の Emacs 必須プラグイン一覧は Magit、Expreg（treesitter expand region）、Multiple cursors、dape（Eglot と連携したデバッグ）だ。おそらく Consult と orderless も追加すると思う。自分の Neovim 設定は ここ で見られる新しい nvim はプラグインの必要性もだんだん減らしている。組み込みのプラグインマネージャ、diff ビューア、LSP が全部入っている
かなりたくさんの nvim プラグインを管理しているんだね！ 自分は先週、nvim の設定を mini.nvim を含む 4 つのプラグインで書き直した。プラグインをたくさん載せると、nvim の安定性と信頼性が一気に落ちると感じた。Emacs では 2 つだけで済むのはうらやましいし、そのほうがずっと安定して動きそうだ。自分の設定は ここ で見られる
数か月使ったあとでも、Pycharm+IdeaVIM の標準セットアップと同じくらいのレベルになると思う？ もちろん自分で設定をいじる楽しさはあるけれど、IDE を効率よく使うことだけに集中するなら、Neovim の設定にたくさん時間をかけるのは少し非効率じゃないかと思う
Expreg（treesitter expand region）は combobulate（まだ使ったことはないけど、よさそう）を思い出させる。ただ、Expreg のほうがずっとシンプルで軽い感じだ
長年 Emacs を使ってきた人たちの話を本当に聞いてみたい。Helix/Vim と比べてどうなのか知りたい。Helix/Vim を初めて使った人は良いと言うけれど、長く使った Emacs の真価を知らずに話しているように見える。たしかに Vim スタイルのキーやモードは最近のエディタのほうがうまく統合されている感じはするが、実際に使うと手が慣れるまで耐える忍耐が自分には足りなかった。本気の hardcore な Emacs ユーザーの乗り換え体験談を聞きたい
自分は Emacs → VS Code → Helix の順で乗り換えてきた。これまでは、できるだけ既存のキーバインドを覚え、設定はほとんど触らずに効率よく使うようにしてきた。Helix ができることを全部覚えるのが大変なので、キーを印刷して机に置くデスクマットを作ってみた。実際に印刷して使ってみないと、どれだけ役立つかはわからないけれど。自分のデスクマットは ここ で見られる
この 10 年は Emacs をメインで使っていて、その前は Sublime Text を使っていた。簡単なファイル編集やリモートサーバーではたまに Vim を使うけれど、Vim だけを完全に使う必要性は感じなかった。Emacs では自分専用のモジュールや関数を作って、ぴったり合う環境を使っていた。先月 Helix を使ってみたが、始めるのが驚くほどシンプルだった。基本的な使い方――移動、検索、貼り付け、バッファ/ウィンドウ切り替え――にもすぐ慣れた。Helix の歴史についてはよく知らないが、とても優れたデザインだと思う。グローバル検索が特に良くて、LSP 連携もちょうどよく機能し、速度も本当に速い。デフォルトが一貫していて実用的にきちんと決まっている感じが、とても快適だ。これからもっと慣れるために使い続けるつもりで、デフォルトのエディタは Emacs のままだが、Helix はあまりに速いので、コーディング編集用としてはメインエディタになり得ると思う
Helix を使い始めたばかりだけれど、2 つの欠点が大きく感じられる
LSP が欠点になる理由がよくわからない。LSP は別プロセスで動くわけで、むしろプラグインのサンドボックス化には向いていると思う。実際、従来型エディタプラグインよりうまく動くことさえあるかもしれない。tmux 統合がないことも、自分は Emacs を主に使っているが内部ターミナルはほとんど使わないので気にならないし、muscle memory さえ移行できるなら、高速な Rust 製エディタというだけでも十分に魅力的だ
Vim のモーションは muscle memory として身につければどこでも使える、という主張はあるけれど、実際にはプラグインや設定なしの素の Vim 環境をそのまま使いたがる開発者はほとんどいない。大半は自分用に細かく調整したセットアップと機能を持つエディタを求める。例外は、複数のマシンに ssh 接続して標準エディタ環境が必須な人くらいだろう。Helix のシンプルさとプラグイン制限について触れていたけれど、もともと Helix はオールインワンエディタを志向していたものの、コミュニティがそれを望まなかったため、プラグインシステムが開発中だ。メインリリースには入っていないが、別ブランチではすでにいくつものプラグインが作られて使われている。プラグインシステムが十分安定するまでリリースを遅らせるのは正しい判断だと思う。Helix の最大の利点は、vi/vim/neovim に残っている扱いづらい UX を改善した点だ。つまり、作業順序を変えることで、コミット前に変更内容を簡単に確認でき、意図しない副作用を減らせる
この程度の設定なら、いっそ vim を使ったほうがいい気がする。Helix の中で vim の機能を再現しようとしているし、Helix 自体も内部的には多くの依存関係を持っている（nvim のように表に見えないだけだ）。自分の vim8 設定は 8 年以上シンプルなまま維持している。vim8 を使うのは、LTS ディストリビューションに入っているバージョンだからだ。自動ロードされるプラグインは 1 つだけで（
vim-tmux-navigatorで vim 分割と tmux 分割を簡単に移動できる）、コードも確認済みで更新もしない。「任意」プラグイン 2 つは vim の内蔵パッケージマネージャで必要なときだけ:packadd!で有効にする。使うのは ale（lsp、診断、保存時自動フォーマット）と vim-fugitive（git 連携）だけ。ale には依存関係がない。vim-fugitive は一度入れておけばそのまま使える。プラグインを自動ロードしないのは、vim の主目的はたいてい素早い編集だからで、長期プロジェクトのときだけ git/LSP を有効にする。不要なプラグインはわざわざ使う必要がない自分も modern Neovim が好きで、この問題を解決するために Python パッケージを 1 つ作っている（特に、すでに Python エコシステムにいる人や uv、pipx を使う人向け）。
uv tool install binwheels-neovimまたはpipx install binwheels-neovimで最新の Neovim をインストールできて、Windows、mac、Linux ですぐ動く。このパッケージは公式 Neovim リリースをラップしていて、uv や pipx を使って OS/アーキテクチャに合ったバイナリを取得する。Linux では公式リリースより古い GLIBC のサポートが必要なので、別途ビルドして提供している。詳しくは PyPI、Github メイン、ビルドログ を参照Helix は nvim+プラグイン群と比べて、サプライチェーン攻撃の表面積がきわめて小さい。Helix 単体で管理されていて、プラグインごとにベンダーが分かれている nvim よりずっと安全だ。Helix はリリースが遅く慎重に進められているので、脆弱性が出ても大きな問題になりにくいよう運用されている
Helix の編集モデルのほうが優れている
Helix を使っていて TUI が必要なら、なぜ neovim ではなく Helix を使うべきなのか気になる。Helix のデフォルトは気に入っているけれど、ある時点から変更したい部分が出てくると、だんだん面倒になってくる気がする。そして Helix で「完全な IDE 体験」を求めるなら、Zed、VSC、JetBrains IDE を使わない理由もよくわからない。自分はシンプルなものが必要なら nvim を使い、もっと機能が必要なら WebStorm を立ち上げるか、同僚が何かを探したいならそれを一緒に見る
低スペックのマシンで ssh 越しに作業するとき、Helix はほぼ即時に起動する。同じ機能を nvim で組むと遅くなるし、設定やプラグインの更新を管理するコストも大きい。それに自分は Rust がわかるので、バグ修正にも貢献できる。C 系言語はわからないから、オープンソースプロジェクトは自分がわかる言語で書かれたものを好む。自分は 12 年間 n/vim だけを使っていて、ここ 2 年で Helix に移った趣味コーダーだ。正直、nvim で恋しくなる部分や、そちらのほうが自然に感じる部分も多いけれど、helix は本当に「すぐ起動」して、その快適さが全部を上回る
この数年、neovim、helix、emacs、nano をそれぞれしばらく使ってみたけれど、helix の out-of-the-box 体験が圧倒的に最高だった。デフォルトが本当によくできていて、コンテキストごとのヘルプやヒントもとても充実しているので、よく使うコマンドは忘れても大丈夫だし、めったに使わないものも簡単に見つけられる。それに、自分の頭の中では helix のコマンドの動作順は vim より自然に感じる。nvim/spacemacs のような最近のエディタは、プラグインや設定のハードルが高すぎる。プラグインエコシステムのおかげで helix に今できないこともできるのだろうけれど（たとえば emacs はどんな lisp 言語でも IDE のように使えるし、helix は repl をロードできない）、そのぶんエディタ本体だけでなく無数のプラグインまで学ばなければならず、検索しても答えがバージョンや組み合わせごとに違って混乱しがちだ。新しく環境を作るときは、結局は他人のおすすめを信じるか、自分で試して学ぶ追加の時間が必要になる。Helix は新しいプロジェクトなので、昔の決定を引きずる負担がなく、現代の開発パターンに合った意思決定とデフォルトを選べる。完璧ではないけれど、TUI 初心者に今すぐ使えるもの、設定なしで手軽に始められるものを勧めるなら helix を推したい
hx は起動も実行も速く、しかも見た目まできれいだ。デフォルトもかなり満足できたので少しだけ手を入れた程度で、終わりのない改善ループにハマっていた emacs/neovim と違って、hx には終わりが見える。TUI はリモートサーバーでもよく動くので、mac、linux、サーバーのどこでも同じ環境を使っている（他のエディタでもできるとはいえ、hx でもしっかり対応している）。必要な LSP もすべて問題なく対応していて、
languages.tomlの設定は少し面倒だったが、他のエディタの設定も同じようなものだったシンプルな設定と、selection-first editing model が好きだ。関連する参考文献は ここ。Vim への適応に苦労する人たちと話してみると、自分はもともと Helix のような「先に選択する」モデルに慣れていたのだと思う。Vim のように対象テキストが見えないまま操作し（コマンドの後に影響範囲が見える）、というやり方には慣れるのが大変だった
エディタ選びは、ものすごく合理的な判断というより、自分の好みや新鮮さ、楽しさといった心理的要因のほうがずっと大きい
:reset-diff-changeコマンドは初めて知った。自分は git でcheckout -pばかり使ってきたけれど、Helix の中で直接できるのはずっと便利だHelix を使って一生懸命慣れて、今ではかなり使いこなせるようになった。でも、その「逆順の作業フロー」は学びやすく実装もしやすい反面、実際に使うと速度が落ちることに気づいた。結局また Vim、それから Zed（Vim モード）に戻った
今日初めて Helix を使ってみたけれど、本当によく設計されたエディタだと思う。とはいえ、
y2$やdwのような Vim の高速な操作ショートカットがないのは惜しいy2$は2xy、dwはwdと書けばいいHelix で空行も含めて現在行を削除する方法がまだ見つからない。
xdは空でない行なら 1 行削除できるが、空行だと 2 行同時に消えてしまうxは現在行を選択し、すでに選択されている状態では次の行へ拡張する。Xは選択を行境界まで拡張する（行単位選択）。Xを使うといい空行では単に
dを使う地味に不便だよね。自分も空行での
xの動作だけを変えた小さな fork を回している。詳しくは この PR を参照