Ki Editor - un editor que funciona sobre AST

• Un editor estructural basado en múltiples cursores que permite manipular directamente la estructura del código y funciona alrededor del árbol de sintaxis (AST)
• Admite interacción a nivel de nodos sintácticos, reduciendo la brecha entre la intención al escribir código y la acción real de edición
• Con la función de múltiples cursores, es posible modificar o refactorizar varios nodos sintácticos al mismo tiempo, mejorando la eficiencia en ediciones masivas
• Redefine la edición modal, permitiendo desplazarse de forma coherente entre distintas unidades como palabras, líneas y nodos sintácticos
• Refuerza la precisión y consistencia en la edición de código, proponiendo un nuevo paradigma que mejora la productividad de los desarrolladores

---

Descripción general de Ki Editor

• Ki Editor es un editor estructural de múltiples cursores (Multi-cursor structural editor) que ofrece un entorno de edición para manipular directamente la estructura sintáctica del código
• A diferencia de la edición tradicional basada en texto, manipula los elementos del código sobre la base del árbol de sintaxis (AST)
• Permite editar directamente por unidad de nodo sintáctico sin necesidad de usar el mouse ni combinaciones de teclado

Interacción con nodos sintácticos

• Mediante la función First-class syntax node interaction, permite trabajar directamente con la estructura sintáctica del código
  • Se enfoca en reducir la brecha entre la intención al escribir código y la acción real de edición
  • Realiza manipulación por unidad sintáctica sin mover el mouse ni usar combinaciones complejas de teclas

Función de múltiples cursores

• Usa Multiple cursors para editar varios nodos sintácticos al mismo tiempo
  • La manipulación paralela de nodos sintácticos mejora la eficiencia en ediciones masivas y refactorización
  • Permite procesar rápidamente tareas repetitivas de modificación de código

Redefinición de la edición modal

• Con la función Redefine modal editing, estandariza el modo de selección
  • Admite de forma coherente el desplazamiento entre distintas unidades como palabras, líneas y nodos sintácticos
  • Refuerza la flexibilidad y consistencia frente a la edición modal tradicional

Relevancia

• Ki Editor ofrece una experiencia de edición centrada en la estructura sintáctica, aumentando la precisión al escribir y modificar código
• Al combinar múltiples cursores con manipulación de nodos sintácticos, presenta un nuevo enfoque de edición de código que contribuye a mejorar la productividad de desarrollo

[GN⁺]

Opiniones de Hacker News

• Al ver la función de “selección sintáctica de primera clase”, me acordé del atajo Expand / Shrink Selection que uso mucho en los IDE de JetBrains
  Con Ctrl + W y Ctrl + Shift + W puedes expandir o reducir la selección por unidades sintácticas
  Esta función cambió por completo mi forma de pensar sobre cómo interactuar con el “texto” de un archivo
  VS Code y Zed también tienen algo parecido, pero siento que expanden/reducen de forma demasiado brusca
  Enlace a la documentación de JetBrains

  • Los atajos de JetBrains que más uso son estos
    Con Cmd+Shift+V abro el portapapeles en pila para buscar o elegir copias anteriores
    Cmd+Shift+E muestra la lista de ubicaciones recientes, y Cmd+Shift+A abre la paleta de acciones para buscar difusamente todos los comandos
    Además, la función Local History permite rastrear cambios de archivos con mucho más detalle que Git
    Estas funciones llevan naturalmente a la idea de “editar directamente desde el búfer de resultados de búsqueda”
  • En Neovim también se puede usar esta misma función con incremental selection basado en tree-sitter
  • Mathematica ofrecía expansión de selección con Alt+. desde principios de los 90
    Doble clic seleccionaba una palabra, triple clic todos los argumentos de una función, y cuatro clics seleccionaban f(a,r,g,s) completo; era una estructura donde la unidad sintáctica crecía según la cantidad de clics
    Todavía tengo esa memoria muscular
  • Estoy investigando control de versiones basado en AST
    Estoy probando la idea de que commits, diff y cherry-pick también funcionen por unidades sintácticas, como Ctrl+W
    El tema está resumido en el proyecto librdx
  • También uso mucho esta función en helix, pero la implementación de vscode no me convence
    La edición con reconocimiento de AST me recuerda la comodidad de los lenguajes de la familia Lisp
    En Lisp, cosas que se resuelven con una simple manipulación de listas en JS requieren LSP o un parser aparte
    Cuando paso un fin de semana usando Clojure y luego vuelvo a TypeScript, de verdad extraño los comandos de paredit

• Hace tiempo hice yo mismo un editor basado en árboles sintácticos
  Como en vez de escribir texto solo se manipula el árbol, no puede existir un programa sintácticamente incorrecto
  Pero el gran reto era convertir eso en un método de entrada realmente usable
  Ahora no puedo ejecutarlo porque ya no tengo el hardware de pantalla de esa época, pero dejé una descripción del proyecto

  • El problema es la restricción de que “la ruta de un programa A a uno B siempre debe pasar por programas válidos”
    Como resultado, a veces hay que pasar por rutas poco intuitivas o incluso reescribir desde cero
    Incluso pueden existir estructuras válidas para las que no haya una ruta de construcción posible
  • Hace tiempo usé en la empresa un lenguaje y editor experimentales basados en JetBrains MPS
    En teoría era interesante, pero me pareció un callejón sin salida poco práctico
    Es difícil vencer la universalidad y simplicidad de una interfaz basada en texto
    Hay demasiadas limitaciones reales: editor dedicado, nuevo sistema de control de versiones, ecosistema aislado, etc.
    Como la gente no piensa en unidades de árbol, programar siempre en un estado sintácticamente correcto era una experiencia extremadamente frustrante
    Al final, son las herramientas que permiten una rigurosidad flexible las que sobreviven en la práctica, como el tipado gradual de TypeScript
  • Si quieres volver a experimentar esos sistemas antiguos, puedes restaurar el entorno VT11 con los emuladores simh y mame
    Material relacionado: simh, mame, código de VT11, documentación
  • Un proyecto llamado Pantograph está retomando esta idea con un enfoque moderno
    Aún no es un editor general, pero la dirección de ampliar rangos de selección de árbol parece prometedora
    Enlace a Pantograph
  • Ahora estoy desarrollando un proyecto sucesor llamado BABLR
    Está construido sobre un sistema de parsing que maneja árboles incompletos pero válidos
    Mediante representaciones de huecos como <//>, puede manejar sintaxis incompleta de forma segura
    Ejemplo: 2 + · puede parsearse como un árbol <BinaryExpression>
    Si te interesa, lo estamos discutiendo en la comunidad de Discord

• No estoy acostumbrado a editar sobre AST
  Solo uso algo como objetos de texto para manejar argumentos de función o arglists
  De las funciones de LSP, solo uso ir a la definición y cambiar nombres
  Al final, esto me motiva a mejorar más mis habilidades con el editor

  • En ese caso, una herramienta como ast-grep es útil
    Puedes escribir patrones con una sintaxis casi igual al código y ver la transformación frente a tus ojos
    Por ejemplo, ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts permite hacer una transformación a optional chaining
    Las metavariables como $X, $A, etc. fuerzan que coincida el mismo nodo
    Los agentes de código con IA todavía no usan bien este tipo de patrones, pero la herramienta en sí es muy sólida
  • En la práctica no hace falta entender a fondo la estructura del AST
    En la mayoría de los casos basta con seleccionar, borrar, copiar o reemplazar por nodos sintácticos
  • Las necesidades de edición sobre AST también varían según el trabajo de cada quien
    Yo no hago refactorizaciones grandes con frecuencia, así que no siento la necesidad de aprenderlo
    Pero alguien que desarrolle servicios grandes podría tener una opinión totalmente distinta
  • Estoy en una posición parecida
    Aprendiendo a escribir macros en Elixir obtuve muchas ideas, y con Lisp pasa algo similar
    Aunque cada lenguaje tenga un enfoque distinto, al final todos van hacia el mismo destino

• La clasificación de editores que yo manejo es esta

  1. Ortodoxos (Orthodox) — centrados en la UI y la integración
  2. Modales (mejora de Vim) — mantienen las combinaciones de teclas existentes
  3. Modales (nuevo enfoque) — reinterpretan la filosofía de Vim
     Ki entra en la tercera categoría, y yo sigo de cerca este tipo de proyectos
  • También hay una cuarta categoría: Emacs, que abarca todo
  • Pienso lo mismo. Ha habido muchos retadores, pero sigo sintiendo que el campeón sigue siendo uno solo
  • Yo también estoy desarrollando un editor de código modal basado en AST
    Los nodos de UI se ven como texto normal, pero en realidad tienen estructura de árbol
    Si quieres dar retroalimentación temprana, contáctame al correo que aparece en mi perfil
  • Si se trata de mejorar Vim, al final sale el chiste de “Ed Visual Mode Improved Improved”

• La dificultad de editar con AST es la descubribilidad (discoverability)
  Está visible en pantalla, pero muchas veces no sabes cómo se llama ese nodo
  Por eso estoy pensando en un plugin que rodee con colores los distintos ámbitos alrededor del cursor para visualizarlos
  La idea es pensar en términos de “moverse al siguiente azul” en vez de “moverse a la siguiente función”

  • En Ki, aunque no conozcas el nombre de un nodo, si presionas d m te muestra las etiquetas de todos los nodos sintácticos visibles para que puedas saltar directamente
  • Aun así, una función general de expandir/reducir selección a nivel AST sigue teniendo mucho valor
    Es útil poder seleccionar hacia adentro o hacia afuera del nodo actual

• Hice una integración de Ki para VSCode
  Después no pude contribuir mucho más y me da pena, pero creo que este tipo de innovación en herramientas base es muy importante
  Enlace a la extensión de Ki para VSCode

  • Sí, es exactamente esa extensión
  • Me cuesta animarme a probar un editor nuevo, así que una extensión para VSCode reduce la barrera de entrada

• Antes de ver ejemplos no lo tenía tan claro,
  pero en “modificación sintáctica de primera clase” me impresionó ver cómo las comas se agregan o eliminan automáticamente
  Incluso parece que la lógica de implementación sería más simple
  Ahora también quiero probar integración de Ki o rewrites basados en AST en Zed

  • Yo hice la extensión de Ki para VSCode, y como usa una arquitectura de comunicación por WebSocket, debería poder integrarse fácilmente también en Zed
    Puedes guiarte por el código del repositorio de Ki

• Pienso probarlo yo mismo pronto
  Me gusta que sea independiente de la distribución del teclado
  También es interesante que esté inspirado en la filosofía de Emacs de que “todo es un búfer editable”
  Claro, como en cada editor los trade-offs son grandes, habrá que probarlo directamente

  • Como el editor está diseñado alrededor del modelo de edición, da pena que haya que volver a construirlo todo cada vez
    Neovim es excelente, pero su modelo de edición tiene límites
    Si la estructura fuera completamente reemplazable, quizá Helix o Ki ni siquiera harían falta
  • Pero para mí la independencia del layout fue una pesadilla
    Lo ejecuté con un teclado Dvorak y los mapeos se rompieron por completo
    Cuando el software cree que es más inteligente que el usuario, al final lo que logra es que el usuario se sienta impotente

• Claro, Emacs ya lo tiene
  El paquete combobulate es un ejemplo

  • Con combobulate puedes hacer una navegación de AST tan natural como editar Lisp
    Con M-k puedes borrar nodos o buscar y editar directamente con consultas de tree-sitter
    Ya está muy bien integrado, pero un editor dedicado a AST todavía tendría margen para llevar la UX más lejos

• Es una función que encaja muy bien con el flujo de trabajo de Helix
  Se siente como si por fin encajara la última pieza del patrón clásico de movimiento → acción