VimからHelixへ移行した感想

 (jvns.ca)
11 ポイント 投稿者 GN⁺ 2025-10-11 | 2件のコメント | WhatsAppで共有
  • 20年間Vimを使ってきた開発者が、Helixエディタへ移行して3か月使った体験を共有
  • Helixは複雑な設定なしで**言語サーバー（LSP）**を標準サポートしている点が魅力的
  • 特にVim/Neovimと比べて優れた検索機能とマルチカーソルなどが改善されており、複数ファイル内で文脈（context）を把握したり一括編集したりしやすい
  • キー入力時にクイックリファレンスのポップアップが表示されるため、ショートカットを忘れずに活用できる
  • Markdownリストの自動生成非対応、永続undoの欠如、週1回程度のクラッシュなどいくつか不便な点はあるものの、全体としては満足できる使用体験
  • 20年間で身についたVimの筋肉記憶を学び直す過程は予想より簡単で、Vim流を無理に持ち込むのではなく**「Helix流」**を学ぶほうがはるかに効果的だった

Helixへ移行した理由

  • Helixを使い始めたきっかけは、言語サーバー統合機能を手軽に利用したかったため
    • Vim/Neovimでの言語サーバー設定は複雑だったが、Helixでは別途設定なしですぐに定義へジャンプやシンボル名の変更などが可能
    • これまでは多数のプラグインや設定ファイルを維持する必要があったが、Helixは標準対応なので負担が減る

Helixの主な長所

  • 検索システムの優秀さ
    • リポジトリ全体で文字列検索をすると、結果がプレビューウィンドウに表示され、一致したファイルをスクロールしながら周辺コードも一緒に見られる
    • Vimのripgrepプラグインと違って結果の文脈が豊富で、素早く判断できる
  • ショートカットの即時参照機能
    • gキーを押すと、移動可能なコマンド一覧がヘルプポップアップで表示され、直感的
    • あまり使わないショートカットも簡単に確認でき、学習コストが緩やか

VimとHelixの違い

  • マーク機能はma、'aの代わりにCtrl+O、Ctrl+Iでカーソル移動履歴をたどる
  • マクロの代わりにマルチカーソル編集を主に使う
    • 文書内での一括変更作業では、%で全選択 → sで正規表現選択 → 必要なマルチ編集を実行
    • 毎回マクロを書くよりもマルチカーソルのほうがずっと便利
  • タブの代わりにspace + bでバッファスイッチャーを使ってすばやく切り替えられる

Helixの不便な点

  • テキストリフロー機能はVimのgqより効果が薄い
    • リストとの相性がよくない
  • Markdownリスト自動生成に非対応
    • リスト項目の末尾で「Enter」を押してもリストが継続されない
    • 箇条書きリストには部分的な回避策があるが、番号付きリストにはない
  • 永続undo機能がまだ未実装
    • Vimではundofileを使って終了後でも変更を取り消せたが、Helixにはまだこの機能がない
  • ファイル自動リロードに非対応
    • ディスク上でファイルが変更された後、:reload-all（:ra<tab>）を手動で実行する必要がある
  • ときどきクラッシュする
    • 週1回程度で、Markdownを多く編集することと関係している可能性がある
    • 再度開けばよいので大きな問題ではない
  • それでもHelixを使い続けている

移行の過程と学習体験

  • 20年間で身についたVimの筋肉記憶を学び直すのは非常に難しいのではないかと心配していた
  • 休暇中のサイドプロジェクトでHelixを使い始め、1〜2週間後にはもう混乱しなくなっていた
  • 最初はVimに似たキーバインドを無理に持ち込もうとしたがうまくいかず、**「Helix流」**を学ぶほうがずっと簡単だった
  • 今でも混乱する部分はある
    • VimのwとHelixのwでは「単語」の定義が異なる（Helixは単語の後ろの空白を含み、Vimは含まない）

ターミナルベースの編集環境

  • 長年GUI版のvim/neovimを主に使っていたため、ターミナルでエディタを使うことには少し慣れが必要だった
  • 最終的に落ち着いたワークフロー
    • プロジェクトごとに別々のターミナルウィンドウを使い、そのウィンドウ内のすべてのタブが同じ作業ディレクトリを持つ
    • Helixのタブをターミナルウィンドウの最初のタブに配置
  • 複数プロジェクトを並行して扱いやすく、以前のワークフローより良い可能性もある

設定

  • Neovimの設定が数百行あったのに比べて、非常にシンプルな設定を維持
    • 主に4つのキーボードショートカットだけを設定
  • 主な設定内容
    • テーマ: solarized_light
    • 既定のyankレジスタを+に設定してシステムクリップボードと同期
    • #をコメントトグルのショートカットに設定（標準のCtrl+Cが気に入らなかった）
    • ^と$を行頭/行末へ移動するよう再マッピング（別のやり方を覚えたくなかった）
    • <space>lを:reflowに設定（文章を多く書くためリフローが頻繁に必要で、vimのgqショートカットが恋しかった）
  • 別途languages.toml設定ファイルで言語ごとの好みを設定
    • Pythonの場合: blackフォーマッタを使用、pyright言語サーバー、自動フォーマットは無効化

結論: 3か月使ってみた印象

  • 3か月はそれほど長い時間ではなく、いつかVimに戻る可能性もある
    • 過去にはnixへ移行した後、8か月でHomebrewに戻った経験がある（ただし、あるサーバー管理には今でもNixOSを使っており満足している）
  • Helixはまだ完成形ではないが、**「設定不要のエディタ」**という方向性が明確
  • シンプルさと標準搭載機能のおかげで、長期的にはVimの代替になりうる可能性がある
  • ただし継続利用するかどうかは、今後の安定性改善と機能拡張次第になりそうだ

関連記事

2件のコメント

 
GN⁺ 2025-10-11
Hacker Newsの意見
  • エディタがたまに segfault で週に1回ほどクラッシュするが、あまり気にしていない、単に再度開けばいいというデータ損失への向き合い方が興味深い。Helix には persistent undo がないので、再度開いても以前の状態には戻らない。
    長いあいだ Vim/Neovim を使ってきて、自分でカスタム設定をしたことも、既存の設定を使ったこともあるが、Vim は本当に好きだ。それでも Helix は、別途設定作業なしですぐ使える点がとても魅力的だ。
    ただ、Helix の config 自体はかなり原始的だと感じるので、実のところ Vim を最初の数年使っただけでも Helix で得られる環境は再現できただろうと思う。そしてそうしていれば、もはや設定地獄はなかったと言いたい。
    ヘルプポップアップが行くべきパスやキーバインドを案内してくれるのがとても良い。普段は「定義へ移動」や「参照へ移動」のような機能を頻繁には使わないので、ショートカットを忘れやすい。こうした文脈ポップアップが広く導入されるといいし、入力をためらったときだけ賢く表示されるなら本当に便利だと思う。
    • すべてのアプリで複雑なキーバインドを使うときに、文脈ヘルプのポップアップがあればものすごく便利だと思う。特に入力が止まったときだけ賢く表示されるならなお良い。
      20年間 Vim/Neovim を使ってきたが、which-key というプラグインを入れたのはつい最近の6か月前で、とても便利に使っている。
      which-key.nvim GitHub
    • Vim における設定問題の文脈を見落としている気がする。
      メインの言語サーバー設定（たとえば「定義へ移動」ができる状態）をきちんと構築しようと何度も試したが、Vim や Neovim で快適な環境を作るのは難しすぎると感じた。
    • Vim の設定を再現できるという点には同意するが、Helix をサーバーにそのまま入れてすぐ使えるのはとても便利だ。
      Vim の設定や関連依存を移す手間がなく、開発環境がずっとポータブルに感じられる（もちろん複雑な Vim 設定ほどではなく、もう少し基本的ではある）。
    • ヘルプポップアップ機能には100%同意する。こういう機能がいろいろな場所で使われれば非常に助かるだろう。
      特にその記事で関連説明とスクリーンショットを見て、この機能を強く欲しくなった。
      timeout などの条件で賢くポップアップが出るなら、必要ないときは邪魔されず、ためらったときだけ自動で案内されるので素晴らしい。
    • Helix を3年間ほぼ毎日使っているが、segfault で落ちたのは数えるほどしかなく、極めてまれな経験だ。ほとんどない。
  • Helix にすっかりハマっていて、すべての開発で使っている。
    それまでは neovim と VS Code を主に使っていたが、Helix が特有の利点を埋めてくれている。
    • デザインが美しい（細部までよく気を配っている）
    • パフォーマンスが速い（遅いと感じたことがない）
    • デフォルトのキーバインドが身体にしっくりくる人間工学的な設計
    • インストール直後から設定なしで使える
      neovim を設定したり vim を使い続けたりするのが面倒で、VS Code と nvim の中間地点が必要だったが、Helix はまさにそれだ。
      もし vimscript の達人だったなら考えは違ったかもしれないが、私はそうではないのでちょうどいい。
      Helix には、もっとモジュール式であることや UNIX 的に振る舞うことは必要なく、今のままでいてほしい。
      すでに多様なツールの Ecosystem があり、Claude Code と連携して使うこともできる（バッファのリフレッシュで新しい編集を反映）。
      最高のエディタのひとつなので、毎月プロジェクトへの支援も始めた。
      今後の発展として望むなら、エディタで画像や数式をレンダリングできる機能がいちばん惜しい。この点は Kitty terminal protocol や sixel のようなプラグインで実装されることを期待している。
      Markdown ファイルでノートやブログ作業をするときに特に役立てたい。
      Helix の健闘を祈る。
    • Helix のようにインストール直後からそのまま使えるアプリは、supply chain attack への心配が減るのでとても安心だ。
      VSCode や (neo)vim は複数箇所からプラグインを取ってこないといけないので、いつも不安だった。
    • nvim と vscode の中間が必要なら、単に vscode に vim プラグインを使えばいいのではないかという疑問がある。
    • 私は helix も好きだが、nvim を捨てるつもりはない。
      Lua の開発者ではないが、LLM は nvim の設定をしたり修正したりするのに大いに役立つ。
      helix に来た最大のきっかけは、LSP/リンター設定がとてもよくできている点だった。
    • 「vimscript の達人」という表現より、実際には neovim では Lua を使うのではないか、という意見。
  • neovim から helix へ数週間移ろうとしてみたが、必須の機能がまだ実装されていないので記録しておく。
    • 保存時の自動コードアクション（例: Go import の追加）: PR #6486
    • telescope+rg のようなファイルピッカーと連動したファジーサーチ: PR #11285
    • ディスク上のファイル変更時の自動バッファ更新: issue #1125
    • ファイルツリーブラウザ機能: プラグインシステムの一環として導入が拒否され、まだ未実装 PR #5768 これ以外にも我慢できる程度の細かなことはいくつかあった。1〜2年後にまた試してみるつもりだ。
    • 私は homebrew で HEAD からよくビルドして Helix を使っているが、Julia がクラッシュしやすいと言っていたのには驚いた。
      HEAD ですでにマージされた機能についていくつか共有すると —

      保存時のコードアクション: 保存時フックで対応可能（Go には適用できる）が、他の言語には適用しにくいかもしれない。
      ファジーサーチ: かなり前から内蔵されており、最近のリワークで大幅に改善された。
      自動バッファ更新: 頻繁にエディタをバックグラウンドに置くので、ぜひ必要な機能だ。
      ファイルツリー: HEAD では Space+e/E で階層型エクスプローラーが使え、比較的最近追加された。

    • リンクされているファイルエクスプローラーは中断されたが、vim-telescope スタイルのエクスプローラーが今年初めに Helix にマージされた。
      すでに内蔵のファジーサーチベースのファイルピッカーがあるので、一般的なファイルエクスプローラーはそれほど追加のユーティリティを提供しない。
    • 私も neovim から helix へ移ろうとしたが、何十年も染みついた vim コマンドの筋肉記憶のせいで小さなミスが積み重なり、すぐ諦めた。
      Helix 用の vim キーバインドプラグインも使ったが部分的にしか合わず、さらに失望が大きかった。
    • templ や sqlc などの外部プログラムがファイルを変更したとき、Helix が自動でファイルを検知して再読み込みしない点が残念だ。
      熟練した Helix ユーザーがどう解決しているのか気になる。
  • Helix を使うようになったきっかけは、主に言語サーバー（LSP）の設定過程にあった。
    Vim/Neovim で快適に言語サーバーを設定するのがあまりに作業になってしまい、Helix に移ることになった。
    ただ、ここ5年の Neovim には batteries included のように必要なものがそろったディストリビューションが現れ、非常に簡単に設定できるようになった。
    多くの開発者がエディタのデバッグに時間を使いたくない、という点には同意する。だから JetBrains が人気なのだと思う。
    ただし、20年の Neovim ユーザーが LSP 環境をまともに構築できなかったという部分は少し納得しにくく、筆者の率直な経験なのか疑わしく感じる。
    • Vim を10年以上使っていても、LSP を一度も設定したことがない例もある。
      結局のところ、その場合でもフル IDE を使うほうが楽で、インストールや設定にはいつもためらいがあった。
    • 私も20年以上 vim → neovim を使ってきたが、LSP が壊れてショートカットまで効かなくなると、原因を探したい気持ちがなくなるという心理的ハードルは大きい。
      筆者の例には共感できる。
    • 驚きだ。og や neovim で LSP 設定に苦労したことはなかった。
      私も設定は最小限の barebones で使うほうだが難しくなく、Lua は vimscript よりずっと人間工学的だと感じる。
      ALE のようなツールを使い続ける理由でもある。
      Helix を使うのも幸せであるよう願っている。
    • まったく奇妙に感じる。Neovim に LSP が内蔵されてからもう2年以上ではなかったか、という疑問。
    • 中堅企業が vscode ツーリングを標準化する傾向が目立つ。
      他のエディタも使えはするが、ほぼすべてのデバッグや設定が vscode 中心なので、それを使うことが推奨される雰囲気がある。
      Neovim+treesitter+LSP の設定も、すでに非常にスムーズにうまくいく。昔は大変だったとしても、今では大きな問題ではない。
      Helix に行く動機が LSP だというのは疑問で、もしかすると筆者の不満は LSP 自体にあるのかもしれない。
  • Helix の noun-verb（オブジェクト→動作）モデルは最初は新鮮だったが、使ってみると verb-noun（動作→オブジェクト）のほうがずっとしっくりくる。
    noun-verb 方式の欠点のひとつは、繰り返しコマンド（.）が使えないことだ。
    Vim では dd..、dap.. などの繰り返し動作が可能だが、noun-verb モデルではこれが難しい。
    さらに根本的にはキー数が足りなくなる問題がある。
    あまりに多くの基本操作で Alt キーを使わなければならず、vim のような normal/visual/insert モードもなく、あるのは visual/insert だけだ。
    motion/オブジェクトの区別も明確ではないため、キーマッピングの難易度が上がり、キー不足の問題が生じる。
    • verb-noun 方式は考え方そのものまで変えてくれる。
      実際にコードを書くときに必要な思考にも、よりよく合っている感じがする。
  • nvim の最近最高の変化は mini.nvim だ。
    echasnovski が作ったプラグイン集で、さまざまなニーズ、一貫性、ドキュメントを満たしてくれる。
    nvim 0.12(nightly) からは内蔵プラグインマネージャー（vim.pack）で mini.nvim と lspconfig だけ入れれば十分だ。
  • lsp のような「高度な」エディタツールを最初からあきらめることが、どれほど自由な体験か驚きを禁じえない。
    neovim をプラグインも自動補完も、さらにはシンタックスハイライトすらなしで使っている。
    こうしたやり方による自己規律のほうが、より良いコードを書けるようにしてくれると感じる。
    すべての人に合うわけではないだろうが、ぜひ一度試してみることを勧めたい。
    • プラグインなし、自動補完なしでもやっていけると言うのに、シンタックスハイライトまで切るのは無駄な苦行ではないか、という意見。
    • まだ私も完全には移行していないが、Emacs では自動補完が1年間壊れたままだが、あまり惜しいとは思わない。
      コードアクションや goto definition も使わず、リアルタイムエラーが多少あるくらいだが、コンパイラが非常に速いので大した意味はない。
      LSP を切ってしまいたい気持ちがある。20年前と比べて、LSP が自分のプログラミング能力を劇的に引き上げてくれたとは思えない。
      シンタックスハイライトについては、派手なカラーテーマのほうがむしろ集中を乱し、意味もないと考えている。
      単色あるいは2色中心のテーマを好み、変数名や関数名の色分けすら必要ないと感じる。
    • Mitchell Hashimoto がこの方法で仕事をうまくこなしていると聞き、最新ツールがなくても十分生産的でいられるという確信を持てた。
      ただ、すべてを記憶しなければならないので疲労が蓄積しないのか、あるいはこの方法が本当により良いコードにつながるのかは疑問だ。
    • 私もどんな補助ツールもなしでコーディングするが、シンタックスハイライトだけは常に有効にしている。
      色はコードのミスやエラーを視覚的に見つけやすくし、コード探索も速くしてくれる、もう一段階多い情報だ。
    • 個人プロジェクトではこのミニマル設定を取り入れている。
      そこまで極端にはせず、シンタックスハイライトと LSP による構文エラーのフィードバックまでは維持している。
      オートコンプリートやドキュメントの自動リンクは使わない。
  • Helix を学びたいなら、nic-revs が作った Helix ドキュメントのリニューアル版を勧める。
    helix-editor.vercel.app
    公式ドキュメントよりずっと見やすく、Tips/Tricks も多いので、効率的な編集方法やキーバインドなど、Helix の欠点（ターミナル内蔵がない点など）を和らげるのに役立つ。
    • 公式ドキュメントの読みづらさにはいつももどかしさを感じていたので、本当にありがたい情報だ。
  • Neovim ディストリビューションの過剰な付加機能は実際に煩わしい。
    長年の vim ユーザーなら kickstart（特にモジュール式フォークの kickstart-modular.nvim）を勧める。
    kickstart.nvim
    とてもミニマルな出発点として素晴らしい。
    • kickstart の利点は、すべての設定が1つのファイルにある点だ。
      ただし規模が大きいので、私は fold marker で区間を折りたたみながら、より管理しやすくしている。
 
qdr7h 2025-10-13

LSPやpluginの設定などが手軽なことから、時折helixに関心を持つものの、手がvi/vimに慣れすぎていて簡単ではありません。