Ki Editor - an editor that operates on the AST

Original Article ↗ Hacker News Discussion ↗

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.