Helix Editor 25.07
(helix-editor.com)- Helix 25.07 では、コアコンポーネントの置き換えと多数の新機能追加が行われた
- ファイルエクスプローラー、LSP ドキュメントカラー表示、コマンドモード改善などにより、使い勝手とワークフローが大きく向上した
- 構文ハイライトとクエリ最適化のため、新しい crate である Tree-house が導入された
- Tree-house は インジェクションおよびローカル処理の能力、性能、保守性を大幅に強化する
- 今後さらに広いマルチランゲージ体験と速度改善の基盤が整えられた
Helix 25.07 主要アップデート
Helix 25.07 リリースは、長らく待たれていたコア機能の置き換えと、さまざまな新機能の追加で構成されている。今回のバージョンには 195人のコントリビューター が参加した。Helix は、複数選択、LSP、Tree-sitter、実験的な DAP サポートを備えた モーダルテキストエディタ である。
新たな主要機能
ファイルエクスプローラー
- 25.07 では
<space>eで使える ファイルエクスプローラー 機能が追加された - このエクスプローラーは telescope に似た UI を提供する
- ディレクトリ内の階層構造を簡単にたどることができ、大規模プロジェクトを探索する際により精密な制御が可能になった
LSP ドキュメントカラー表示
- Helix は LSP サーバーにドキュメントカラー情報を要求し、RGB カラー範囲をインラインで表示できるようになった
- たとえば tailwindcss-language-server や vscode-css-language-server などから色を受け取り、コード内でその場でカラーボックスを視覚的に確認できる
コマンドモード (:) の機能改善
- コマンド解析および自動補完コードの全面書き直しにより、バグが修正され使い勝手が向上した
:write系コマンドに--no-formatフラグなどの フラグ対応 が追加された- コマンド内の変数/値展開(
%{variable_name}、%sh{コマンド}など)機能と自動補完が導入された - 複雑な入力値処理のため、拡張性のあるパーサ構造に変更され、今後のコマンド拡張が容易になった
Tree-house: Tree-sitter 統合の新構造
Tree-sitter とは
- Tree-sitter は高速でエラーに強いパーサを生成・活用するためのフレームワークである
- 文法 DSL でパーサ規則を記述し、エディタやツール内で構文木を生成して活用する
- 例として、GitHub のコード探索・ハイライト、コードサーバーの spell-check、diff ツールなどで使われている
- Tree-sitter クエリはサブツリーのパターンマッチングや構文ノードのキャプチャに活用される
Helix の従来の Tree-sitter 連携と問題点
- Helix 初期には公式 Rust バインディング(
tree-sittercrate)とtree-sitter-highlightハイライターを利用していた tree-sitter-highlightは 非インクリメンタル で、常に文書全体を再パースする必要があり、性能低下やリソース浪費の問題があった- Helix はこれを改善するため独自のハイライターをフォークしたが、次第に複雑化して保守が難しくなっていた
Tree-house の導入と利点
- Tree-house は 分離されたパース/クエリ構造、クリーンなコード、既存の慢性的なバグの解消、将来志向の構造(並列パースなど)に重点を置いている
- 最大の強みは インジェクション (Injection) の堅牢な処理である
インジェクション (Injection): 複数言語/レイヤー対応
- インジェクションとは、たとえば Markdown 内に Rust のコードブロックが現れたとき、その範囲だけを Rust として別途パースする方式である
- 複雑なケース(例: Rust コメント内の Markdown、その内部コードブロック内の Rust など)も、ツリー構造でレイヤーを管理することで正確に対応する
インクリメンタルなインジェクション
- 実際に変更が発生したレイヤーだけを高速に再パースし、クエリを実行することで、最小作業単位だけを扱う
- 非常に大きなリストやネスト構造を持つ Markdown 文書で効率を最大化できる
ローカル変数ハイライト (locals)
- 関数内のパラメータなどローカル変数を、宣言と参照範囲(スコープ)にわたって正確にハイライトする
- 従来は定義がビュー外にあるとハイライトが消えるという 慢性的な問題を Tree-house で解決した
グローバル化されたインジェクション対応
Syntax型ではインジェクションレイヤーの探索と参照が 対数時間 (logarithmic time) で可能になったTreeCursor、QueryIterなどの API により、すべてのインジェクションレイヤーへの適用が可能になった- HTML の
<script>内コードや Markdown コードブロックなど、言語境界をまたぐ一貫した動作を実現する基盤が整えられた
まとめ
- Helix 25.07 は、ファイルエクスプローラー、カラーインレイ、コマンドモード/パーサ改善といった 使い勝手の革新に加え、Tree-house ベースの新構造導入により、次世代テキストエディタの有力候補として浮上している
- 詳細な更新内容は changelog を参照できる
- コミュニティ参加やコントリビューションは Matrix、GitHub リポジトリを通じて行える
1件のコメント
Hacker Newsのコメント
Helixは本当に素晴らしい。ファイルピッカー、構文ハイライト、lintingなど多くの機能が、プラグインの導入や複雑な設定なしで最初から使える。一方でvimやneovimは基本的にかなりの設定が必要だ。使いたい気持ちはあるが、最大の欠点はキーバインドの挙動がvimと違うことだと思う。慣れ親しんだ
xでカーソル下の文字を削除したり、dで後続の操作を待ったりといった、長年使ってきたvimの手になじんだ動作がそのままでないと、混乱するし苛立ってしまう。おそらく多くのvimユーザーもこの点では似た感覚を持つだろうし、習慣を変えるのはとても難しい。特にvimはどこにでも標準であるので、そこから抜け出せない環境でもある。幸い、evil-helixというHelixのソフトフォークがVimキーバインドを追加してくれるので、私と同じ不便を感じている人に勧めたい。また、Helixとevil-helixはWindows(cmd)でもrustのインストールなしに.exeを受け取るだけですぐ問題なく動く私にとっては新しいものを学びたくないからではなく、このキーバインドを他の場所で使えないことが問題だ。ほぼすべてのオンラインエディタやワークステーションはvimキーバインドを提供しているし、Linuxにssh接続すれば常にvimがあるという点が重要だ。ちょうどQWERTYキーボードのように、より優れた配列があったとしても、ほぼすべての環境に即座に適応できる柔軟性は手放せないということだと思う
新しいツールを学ぶこと自体にまったく問題はない。Helixも十分使ってみたが、名詞-動詞モデルはむしろ良くないように思えたし、視覚的フィードバックもコードを読むときにはかえって邪魔になる。vimでは単純に最後のコマンドを繰り返すこと(
.バインドなど)が楽にできるが、Helixではそれを諦めなければならない。状態管理についてもvimより気を使う必要があり、vimではファイル内の現在位置だけを気にすればいいが、Helixでは自分がどこにいたかまで考えなければならない。私は、デフォルト設定が良く、モーダル編集があり、必要以上の視覚的同期を強制しないエディタを求めている。同期が多いと編集言語としての利点が失われる。編集そのものよりもっと面白いプログラミングに集中したい。より高い集中力を要求するエディタは、むしろエディタとしては良くないvim(neovim)を20年近く使ってからhelixに移行したが、まったく難しくなかったし、今ではずっとこちらを好んでいる。いくつかのモーダル動作は調整したが、helixの論理に従って使っている。マルチセレクションやLSPのような機能が標準で備わっており、複数ステップの入力時に可能な操作をヒントとして表示してくれる強力なヘルプが大きな利点だ。たまに素のvimを使うことがあっても、頭の中のマッピングが多少変わっていても、基本的なコマンドは覚えているので、すぐに修正できる
Helixは現在、プログラマブル設定のためのSchemeを追加している。プログラマブル機能が入れば、今のemacsのrepeat / transient map、状態ごとの追跡など、さまざまな微調整が可能になる見込みだ。LLMsの革新のおかげで8番目、9番目の言語にも簡単に触れられる世界では、繊細な設定が可能なツールが市場でさらに存在感を増すだろうと思う
Vimキーバインドが、Helixを使わない唯一の理由だった。外部フォークを通じてvim対応が可能なら、Helix公式でもやろうと思えば対応できるはずなのに、あえてやっていないのだろうかと思ってしまう
Helixが本当に好きだ。vimがあまり合わなかった人や、vimのコンセプトは好きだけれど簡単には馴染めなかった人には強く勧めたい。既存のvim系よりずっと学びやすく使いやすかったし、標準で提供される設定もとても実用的だ
こういう優れた能力を持つエディタが、今もミニマルで、無駄なAI機能に集中していないのは好ましい
お祝いを述べたい。Helixの成功を願っているが、自分には合わない気がする。私はNeovimを使っていて、やりたいことはほぼすべてできる。でも完全に満足しているわけでもない。私が求めるエディタの条件は次のとおりだ:
私もVimの筋肉記憶は認めるが、多くの人はここに執着しすぎている気がする。私はOS、エディタ、IDEを何度も乗り換えてきたし、変えた最初の数日はものすごくもどかしくて腹が立って、いっそ農業でもやるかと思うくらいだけれど、その時期を過ぎればいつも新しい筋肉記憶ができる。数日の不便のために、ソフトウェアの他の数多くの利点を捨てるのはもったいないと思う
Helixが挙げられた条件のどこを満たしていないのかははっきりしない。私にはHelixがほぼすべて満たしているように見える
要件を見ると、結局はNeovimでLuaだけを別の言語に置き換えたいように見える
Helixが大好きだ。お祝いを伝えたい。デフォルトテーマがきれいで、標準設定も素晴らしい。インストールするだけですぐ使えて、特別な設定も必要ない。完全にIDEを置き換えたわけではないが、
viにaliasを張り、$EDITORもHelixに設定している。CLIで素早い修正やデバッグが必要なときは、いつもHelixを使うことになるHelixは本当に好きで好感も持っていたが、undoの挙動はどこか論理的ではなく、一度に取り消される内容が多すぎるなど不自然だった。このせいで実際に作業を失ったこともある
Undoについて不便だった点が2つある:
Undoと「最後のコマンド繰り返し」は少し変だが、他の機能が良いのでメインエディタとしてHelixを使っている。ところで、作業を失った部分についてはredoはできなかったのだろうか
Helixに「Kakouneモード」ができてほしい。会社ではWindowsを使っているのでKakouneは最適ではなく、Helixが完璧に見えたが、キーバインドの壁を越えにくい。Helixのキーバインド哲学はKakouneの簡潔さよりもさらに冗長で、その点が気になる。また、Helixのキーバインド設定はKakouneをきちんと再現できるほど強力ではないのも残念だ。私はvimの不整合さや非論理的な挙動に失望してKakouneに移ったので、Helixはこの点では一段後退したように感じる
「ポストモダン」エディタという言い方が面白い。Fishシェルの「90年代のためのシェル」以来、2番目に良いジョークのように思う。動画で見るとTUIベースなのが印象的で、Emacs TUIっぽさが少し残っている
Helixレベルのオールインワンな完成度を持つvimライクなエディタが本当に必要だ。Neovimディストリビューションは各要素の結合が緩すぎて、いつも何かしら微妙に不便だ。Vimインターフェース全体を再設計する必要があるとも思うが、動作-オブジェクト中心のモーダル方式は維持されてほしい
Evil-Helixがそういう要望に合っていそうだ。荒削りな部分もまだ多そうだが、確認してみる価値はある https://github.com/usagi-flow/evil-helix
Action-Objectモーダル方式とは何か気になる
Helixや類似エディタの構文ハイライトやコード理解機能についての詳細な説明が印象的だった。tree-sitterベースの構造と機能はクエリ言語にぴったりな感じがして、シンボル検索や参照検索を超えて、汎用的なクエリDSLまで可能に見える。こうした機能がすでに存在するのか気になる