Ki Editor - ASTベースで動作するエディタ

 (ki-editor.org)
2 ポイント 投稿者 GN⁺ 2026-03-08 | 1件のコメント | WhatsAppで共有
  • コード構造を直接操作できるマルチカーソルベースの構造的エディタで、構文木（AST）を中心に動作
  • 構文ノード単位のインタラクションをサポートし、コードを書く意図と実際の編集動作のギャップを縮小
  • マルチカーソル機能により複数の構文ノードを同時に修正・リファクタリングでき、大規模編集の効率を向上
  • モードベース編集方式を再定義し、単語・行・構文ノードなどさまざまな単位での移動を一貫した方法で実行可能
  • コード編集の正確性と一貫性を強化し、開発者の生産性を高める新しい編集パラダイムを提示

Ki Editor の概要

  • Ki Editor は**マルチカーソル構造的エディタ（Multi-cursor structural editor）**で、コードの構文構造を直接扱う編集環境を提供
  • 従来のテキストベース編集とは異なり、**構文木（AST）**をベースにコード要素を操作
  • マウスやキーボードの組み合わせなしで、構文ノード単位で直接編集が可能

構文ノードのインタラクション

  • First-class syntax node interaction 機能により、コードの構文構造を直接扱う
    • コードを書く意図と実際の編集動作の間にあるギャップを減らすことに重点
    • マウス移動や複雑なキー入力なしに、構文単位の操作を実行

マルチカーソル機能

  • Multiple cursors を活用して複数の構文ノードを同時に編集可能
    • 並列的な構文ノード操作により、大規模編集およびリファクタリングの効率を向上
    • 反復的なコード修正作業をすばやく処理

モードベース編集の再定義

  • Redefine modal editing 機能により選択モードを標準化
    • 単語、行、構文ノードなどさまざまな単位での移動を一貫した方法でサポート
    • 既存のモードベース編集よりも柔軟性と一貫性を強化

意義

  • Ki Editor は構文構造中心の編集体験を提供し、コード作成と修正の正確性を高める
  • マルチカーソルと構文ノード操作を組み合わせ、開発生産性の向上に貢献する新しいコード編集アプローチを提示

関連記事

1件のコメント

 
GN⁺ 2026-03-08
Hacker Newsのコメント

  • 「First-class syntactic selection」機能を見て、JetBrains IDEでよく使う Expand / Shrink Selection のショートカットを思い出した
    Ctrl + W, Ctrl + Shift + W の組み合わせで、選択範囲を文法単位で拡大・縮小できる
    この機能のおかげで、ファイルの「テキスト」とやり取りする方法に対する見方が完全に変わった
    VS CodeやZedにも似た機能はあるが、拡大・縮小が粗すぎる感じがある
    JetBrainsドキュメントリンク

    • 私がよく使うJetBrainsのショートカットは次の通り
      Cmd+Shift+V でスタッククリップボードを開き、過去のコピー履歴を検索したり選択したりできる
      Cmd+Shift+E は最近の場所の一覧を表示し、Cmd+Shift+A はアクションパレットを開いてすべてのコマンドをあいまい検索できる
      さらに Local History 機能で、Gitよりはるかに細かくファイル変更履歴を追跡できる
      こうした機能は「検索結果バッファからその場で編集する」という概念につながる
    • Neovimでも tree-sitter ベースの incremental selection で同じ機能を使える
    • Mathematica は90年代初頭から Alt+. で選択拡張機能を提供していた
      ダブルクリックで単語、トリプルクリックで関数引数全体、4回クリックで f(a,r,g,s) 全体を選択するというように、クリック回数に応じて文法単位が大きくなる仕組みだった
      今でもその筋肉記憶が残っている
    • 私は ASTベースのバージョン管理 を研究中だ
      コミットや diff、cherry-pick でも Ctrl+W のように文法単位で動作させるアイデアを試している
      関連内容は librdxプロジェクト にまとめてある
    • helix でもこの機能をよく使うが、vscode の実装はいまいちだ
      ASTを意識した編集は Lisp系言語の便利さ を思い出させる
      Lisp では単純なリスト操作でできることでも、JS では LSP や別のパーサーが必要になる
      週末に Clojure を使ってから TypeScript に戻ると、paredit コマンドが本当に恋しくなる

  • 以前 構文木ベースのエディタ を自作したことがある
    テキストを入力する代わりに木だけを扱うので、文法的に誤ったプログラムは存在しえない
    ただ、実用的な入力方式として成立させるのが大きな挑戦だった
    今は当時の表示ハードウェアがないので実行できないが、プロジェクト説明 は残してある

    • 問題は「プログラムAからBへ行く経路が常に有効なプログラムでなければならない」という制約だ
      その結果、直感的でない経路を通ったり、最初から書き直すしかない場合が生じる
      さらには有効ではあるが生成経路が存在しない構造すらありうる
    • 以前、会社で JetBrains MPS ベースの実験的な言語とエディタを使ったことがある
      理論的には興味深いが、実用性の低い袋小路だと感じた
      テキストベースのインターフェースの 普遍性と単純さ に勝つのは難しい
      専用エディタ、新しいバージョン管理、エコシステムの断絶など、現実的な制約が大きすぎる
      人は木単位で考えるわけではないので、常に文法的に正しい状態でしかコーディングできないのは 極めて窮屈な体験 だった
      結局、柔軟な厳密さ を許すツール（例: TypeScript の段階的型付け）が実際に生き残る
    • 古いシステムをもう一度体験したいなら、simh と mame エミュレータで VT11 環境を復元できる
      関連資料は simh, mame, VT11コード, ドキュメント を参照
    • Pantograph というプロジェクトがこのアイデアを現代的に再挑戦している
      まだ汎用エディタではないが、木の選択範囲を拡張する方向性は有望に見える
      Pantographリンク
    • 私は今 BABLR という後継プロジェクトを開発中だ
      不完全だが有効な木を扱うパーサーシステムの上に構築されている
      <//> のような ギャップ表現 によって、不完全な構文を安全に扱える
      例: 2 + · を <BinaryExpression> 木としてパースできる
      興味があれば Discordコミュニティ で議論している

  • 私は AST 編集には慣れていない
    関数引数や arglist を扱う テキストオブジェクト 程度しか使わない
    LSP 機能も定義へ移動と名前変更くらいしか使わない
    結局、エディタの腕をもっと上げなければという刺激 を受けた

    • こういう場合は ast-grep のようなツールが便利だ
      コードとほぼ同じ文法でパターンを書き、その場で変換結果を確認できる
      たとえば ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts のように オプショナルチェイニング変換 ができる
      メタ変数 $X, $A などは同一ノードのマッチを強制する
      まだ AI コーディングエージェントはこうしたパターンをうまく使えないが、ツール自体は非常に堅牢だ
    • 実際には AST 構造を深く理解していなくてもよい
      たいていは 構文ノード単位で選択して削除・コピー・置換 できれば十分だ
    • 人によって仕事が違うので、AST 編集の必要性も異なる
      私は大規模リファクタリングを頻繁にしないので、わざわざ学ぶ必要を感じない
      ただし大規模サービスの開発者なら、まったく違う意見かもしれない
    • 私も似た立場だ
      Elixir で マクロを書くこと を学び、多くの洞察を得たし、Lisp も同じ文脈にある
      言語ごとにアプローチは違っても、結局は同じ目的地に向かっている

  • 私の見るエディタ分類は次の通りだ

    1. 正統派(Orthodox) — UIと統合性重視
    2. モーダル型(Vim改善) — 既存キーバインドを維持
    3. モーダル型(新アプローチ) — Vim の哲学を再解釈
      Ki は3番目の部類に属していて、私はこういうプロジェクトを継続的に追っている
    • 4つ目の分類もある — すべてを包み込む Emacs
    • 私も同じ考えだ。挑戦者は多かったが、いまだに チャンピオンは一人 だと感じる
    • 私も AST ベースのモーダルコードエディタを開発中だ
      UI ノードは普通のテキストのように見えるが、実際には木構造になっている
      初期フィードバックをもらえるなら、プロフィールのメールに連絡してほしい
    • Vim 改善といえば、結局「Ed Visual Mode Improved Improved」という冗談が出るほどだ

  • AST 編集の難しさは 発見可能性(discoverability) にある
    画面には見えていても、そのノードの名前が分からないことが多い
    そこでカーソル周辺を色で囲み、各 スコープを可視化 するプラグインを構想している
    「次の関数へ移動」ではなく「次の青へ移動」というふうに考えるやり方だ

    • Ki ではノード名を知らなくても d m を押せば、現在見えているすべての構文ノードのラベル を表示してそのまま移動できる
    • それでも 一般的なASTレベルの選択/縮小機能 には依然として価値がある
      現在のノードの内側や外側を選択するような操作が有用だ

  • 私は VSCode向け Ki 統合 を作った
    その後あまり貢献できず残念だが、こうした 基盤ツールの革新 は非常に重要だと思う
    Ki VSCode拡張リンク

    • そう、その拡張機能だ
    • 新しいエディタを試すのは気が重いが、VSCode 拡張が 参入障壁を下げてくれる

  • 実例を見るまではよく分からなかったが、
    「First-class syntactic modification」でカンマが自動で追加・削除されるのを見て感心した
    実装ロジックもむしろ単純そうだ
    これで Zed でも Ki 統合や ASTベースのリライト を試してみたくなった

    • 私が Ki の VSCode 拡張を作ったが、WebSocket 通信構造 なので Zed でも簡単に連携できる
      Ki リポジトリのコードを参考にするとよい

  • 近いうちに実際に使ってみるつもりだ
    キーボードレイアウト非依存 という点が気に入った
    Emacs の「すべてが編集可能なバッファ」という哲学に着想を得ているのも興味深い
    もちろんエディタごとに トレードオフ が大きいので、実際に使ってみないと分からないと思う

    • エディタが 編集モデル中心に設計された構造 なので、毎回すべてを作り直さなければならないのが惜しい
      Neovim は素晴らしいが、編集モデルには限界がある
      もし完全に置き換え可能な構造だったなら、Helix や Ki は必要なかったかもしれない
    • ただし レイアウト非依存性 は私にとっては悪夢だった
      Dvorak キーボードで起動したらマッピングが完全に壊れた
      ソフトウェアがユーザーより賢いと思い込むと、かえってユーザーは 無力感を覚える

  • やはり Emacsにはすでにある
    combobulate パッケージがその例だ

    • combobulate を使うと Lisp 編集のように自然な AST ナビゲーション ができる
      M-k でノードを削除したり、tree-sitter クエリで直接検索・編集したりできる
      すでに優れた統合になっているが、AST専用エディタ なら UX をさらに発展させる余地がある

  • Helix のワークフローに本当によく合う機能だ
    既存の 移動 → アクション パターンに最後のピースがはまった感じだ