- Helix は、現代的な機能を統合したターミナルベースの モーダルテキストエディタ であるオープンソースプロジェクト
- Tree-sitter 統合により、シンタックスハイライト、インデント計算、コードナビゲーションなどの 構文認識編集機能 を提供
- Language Server Protocol をサポートし、自動補完、定義ジャンプ、ドキュメント表示、診断などの IDE レベル機能 を実現
- Rust で書かれており、Electron や JavaScript なしで動作し、SSH・tmux・ターミナル環境 で効率的に利用可能
- プラグインシステムと GUI フロントエンド は今後開発予定で、軽量なコードベースとモダンなデフォルト設定 を特徴とする
主な特徴
- Helix は Kakoune に着想を得た マルチセレクションおよびカーソルシステム を中核の編集単位として使用
- コマンドが複数の選択領域を同時に操作し、並列コード編集 が可能
- Tree-sitter を使ってエラー耐性のある構文木を生成
- これにより、正確なシンタックスハイライト、自動インデント、コードナビゲーション 機能をサポート
コード操作およびナビゲーション機能
- 関数、クラス、コメントなど 構文木ノード単位での選択および移動 機能を提供
- 単純なテキストではなく 構文構造ベースの編集 が可能
- 言語サーバープロトコル（LSP） を通じて、言語ごとの 自動補完、定義ジャンプ、ドキュメント表示、診断 機能を提供
- 追加設定なしで IDE レベルの機能をターミナル環境で活用可能
技術的基盤
- Rust で書かれており、安定性と性能 を確保
- Electron、VimScript、JavaScript を使用しない
- SSH、tmux、一般的なターミナル 環境で動作可能
- 軽量な構造により バッテリー効率 が向上
内蔵されたモダンな機能
- ファジーファインダー（fuzzy finder） によるファイルおよびシンボル探索、プロジェクト全体検索 をサポート
- 自動括弧閉じ、surround 統合、テーマのカスタマイズ など、さまざまな便利機能を内蔵
- 別途プラグインがなくても 基本機能が豊富に統合 された構造
よくある質問
- 「ポストモダン」という表現は、Neovim が『モダンな Vim』なら Helix はその次の世代 という冗談めいた意味
- GUI フロントエンド は今後 WebGPU ベースのプロトタイプ として開発予定
- 現在 プラグインシステムは未実装 の状態で、今後導入予定あり
- Kakoune との違いは、Helix が より多くの機能を内蔵 し、Tree-sitter ベースのコード解析 を使用している点
- Vim とは異なり、Helix は ゼロから新しく設計されておりコードベースが小さく、設定ファイルの調整を最小限にしたモダンなデフォルト値 を提供
コミュニティと参加
- GitHub でコードへの貢献が可能
- Matrix チャンネルでプロジェクトの議論を実施
- OpenCollective を通じて開発支援が可能
1件のコメント
Hacker Newsの意見
「Post-modern?!」という冗談を見て興味を引かれた
多くのエンジニアは 「postmodern」を単に modern の次の段階として理解しているが、これは芸術・人文学における本来の意味とは異なる
もちろんこうした用法が大きな問題というわけではないが、それでも本当に「ポストモダン」な創造性を期待していたので目に留まった
ただ、「postmodernism」がもともと modernism の後に生まれた反応としての概念である点を考えると、単に「modern の次」と解釈するのも完全に間違いとは言えないと思う
ただ、時間が経つにつれてその意味はずっと複雑になり、今では「dated af」と感じられるのが逆におかしくもある
「Helix、巨大な物語を信じない最初のエディタ。Helix、相対主義的エディタ。Helix、Foucault と Derrida の最新アップデート搭載」
ここ数年、Helix をメインのエディタとして使っている（Sublime → Atom → Vim → Helix）
たいていの LSP はほぼ 設定なしで動作し、設定ファイルも昔の .vimrc よりはるかに簡潔だ
Vim の筋肉記憶を書き換えるのにも数日しかかからなかったが、それでも モーダルエディタに対しては複雑な感情がある
コードフォールディング機能はまだ待っているところだ
Emacs では multiple cursors や treesitter ベースのプラグインを使えば、非モーダル方式でも強力な編集が可能だ
もしかして似たような理由で Helix のモーダル方式が不便なのだろうか
昔の Unix キーボードではホームロウの近くにあったが、今は遠すぎる
ほとんどのチュートリアルが代替キーに触れないので、いまだに半分以上のユーザーが Escape をそのまま使っているのが理解できない
数日前に Helix をまた使ってみたが、AI を LSP 経由でしか使えない点はまだしも、
外部でファイルが変わっても自動リロードされない点がとても不便だった
AI が修正したファイルが最新状態なのか、ずっと気にし続けることになる
こういう方式のほうがずっと安定していて魅力的だ
一方で一部の AI ツールは「IDE は不要だ」と言って CLI 中心で進めているが、それは完全な たわごとだと思う
:reloadと:reload-allコマンドがある自分は
Ctrl-rに reload-all を割り当てている別の選択肢としては mux があり、LLM が提案した変更に 行・ブロック単位でコメントできる（まだ初期バージョン）
Claude Code で作業するとき、ファイルが自動で変わらないのが気に入っている
Vim は C、Helix は C++、Ki Editor は Rust のようだ
Helix は Vim のアイデアを多く受け継いでいるが、キーバインドの一貫性に欠け、概念的な組み合わせも弱い
たとえばバッファでは
kで移動できるのに、ファイルエクスプローラではctrl+nを使わなければならないkは入力文字として使われるので、別のキーを使う必要があるHelix も同じ理由だろう
SSH 接続時にキーボードレイアウトが違ったらどうするのか疑問だ
Helix を本当に好きになりたかった
デフォルト設定はよくできていて、学ぶために Vim の習慣をあえて捨てたが、
結局 キーバインドが単純な実装のための妥協だという結論に達した
今は小さな修正には Neovim、大きな作業には Zed（vim モード）に戻っている
たとえばファイルを開き直しても前回のカーソル位置に戻らない
LLM で修正はできたが、結局 Helix のフォークを保守したいとは思わなかった
長年積み上がった 筋肉記憶を捨てるのは本当に大変だ
自分は hx + Zed の組み合わせがかなり良いと感じている
Helix は ライブファイル更新をサポートしていないので、コードエージェントと一緒に使うには不便だ
Helix の FAQ の 2 番目の質問を見るといい
Python LSP が 設定なしですぐ動作して印象的だった
ただ、25 年分の Vim の筋肉記憶のせいで、Helix の微妙な違いがあまりにも紛らわしい
結局のところ問題は Helix ではなく、自分の筋肉記憶だ
Vim と Helix もそうなれる気がする
M-ESC ESCを 無害なコマンドにバインドすれば、ウィンドウが閉じる問題を避けられる例:
(global-set-key (kbd "M-ESC ESC") 'keyboard-quit)ddやGなどの違いに慣れれば、だんだん良く感じるようになるここ数年、Helix をデフォルトエディタとして使っている
シンプルさ、速さ、キーボード中心のナビゲーション、そして Elixir LSP 統合が特に気に入っている
Helix をメインとして多くのコードをデプロイしてきた
設定ファイルは 50 行もなく、一部の Vim キーを追加しただけだ
Vim と Helix を行き来しても大きな問題はない
自分の設定は ここ にある
VS Code で直接 モーダルモード拡張を作ったことがあるが、Kakoune や Helix のアプローチは興味深かった
「変更される部分をあらかじめ見せる」構造と、マルチカーソル中心の設計が合理的に感じられた
しかし数週間後には結局 古典的な Vim スタイルへ戻った
マルチカーソル方式は、画面上ですべての変更点を見渡せるときにしか有用ではなかった
最近は AI のおかげでコードより 文章を書くことのほうが増え、こうした編集方式の価値が下がったように感じる
mc-hide-unmatched-linesコマンドがあり、カーソルのある行だけ表示できるマルチカーソルは 短く単純な編集には向いているが、複雑な修正にはバッチ編集ツールのほうが効率的だ
画面外カーソル問題を解決するために作られた