Ki Editor - an editor that operates on the AST

Original Article ↗ Hacker News Discussion ↗

An experimental code editor called Ki, which operates directly on abstract syntax trees (ASTs) rather than plain text, is prompting comparisons with Vim, Helix, Emacs, JetBrains IDEs, and older structural editors. Commenters weigh its promises—more precise structural refactoring, multi-cursor operations grounded in syntax, and keyboard-layout-agnostic, modal workflows—against practical challenges such as discoverability of AST operations, muscle-memory friction, integration with existing ecosystems, and the need for specialized tooling. The exchange also situates Ki within a longer history of AST-based and structure editors, questioning whether such models can gain traction in a world increasingly shaped by LSPs, regex-heavy workflows, and AI-assisted refactoring.

Positioning vs. other editors

  • Seen as a “modal, rethinking Vim” editor that operates directly on the AST, distinct from:
    • “Orthodox” GUI editors focused on looks/integrations.
    • Vim/Helix-style modal editors that mostly refine classic Vim.
  • Compared frequently to Vim, Neovim, Helix, Emacs, JetBrains IDEs, and tree-sitter plugins.
  • Some argue much of Ki’s AST-aware behavior can already be approximated via tree-sitter textobjects, incremental selection, LSP rename, or structural editing packages in other editors.

AST-first editing & syntactic selection

  • Strong interest in “first‑class syntactic selection” and modification:
    • Expand/shrink selection similar to JetBrains’ Ctrl+W, Neovim’s incremental selection, and Helix’s features.
    • Structural operations that automatically handle commas, argument boundaries, etc.
  • Multi-cursor + AST selection is pitched as a major advantage over pure text search/replace and macros, especially for consistent syntactic edits.
  • Others argue regex, search/replace, and LSP refactorings are usually enough; macros and multi‑cursor are seen as niche or overkill by some.

Keybindings, modes, and ergonomics

  • Ki’s keymap is described as coherent and keyboard-layout agnostic, with “selection mode” and momentary layers (hold-keys combos via kitty protocol).
  • Some Vim users dispute claims that Vim/Helix bindings are incoherent, saying Vim’s operator–motion model feels highly logical once learned.
  • Muscle memory friction is noted (e.g., Ki’s motion keys differing from Vim’s), and layout-agnostic design can misbehave with hardware-level layouts like Dvorak.

Integrations & ecosystem

  • There is a VS Code extension that bundles the Ki binary; a Neovim keybinding plugin is in progress, but some Ki behaviors are hard to reproduce due to Neovim’s architecture.
  • Emacs users point out existing structural-editing packages and consider possible Ki-style bindings.

History, theory, and limitations

  • Several commenters reference earlier and more “hard-core” tree editors where you can only construct valid ASTs, often finding them clumsy or impractical.
  • Concerns raised:
    • Discoverability of AST node types and actions.
    • Handling of incomplete or invalid code; some expect tolerant parsing, others mention “holes” in trees.
    • Ecosystem cost: needing special editors, tooling, and workflows versus the universality of plain text.
  • Enthusiasm centers on reduced syntactic errors and more powerful refactoring; skepticism centers on learning cost and whether benefits justify switching.