Helix Editor 25.07

• Helix 25.07 incluye el reemplazo de componentes centrales y la adición de múltiples funciones nuevas
• La usabilidad y el flujo de trabajo mejoran considerablemente con el explorador de archivos, la visualización de colores de documentos vía LSP y mejoras en el modo de comandos
• Se introduce un nuevo crate, Tree-house, para optimizar el resaltado de sintaxis y las consultas
• Tree-house refuerza ampliamente las capacidades de inyecciones y manejo de variables locales, además del rendimiento y la mantenibilidad
• También sienta las bases para futuras mejoras en la experiencia multilenguaje y la velocidad

---

Principales actualizaciones de Helix 25.07

La versión Helix 25.07 trae un reemplazo de funciones centrales largamente esperado y una variedad de nuevas características. En esta versión participaron 195 contribuidores. Helix es un editor de texto modal con múltiples selecciones, LSP, Tree-sitter y soporte experimental para DAP.

Nuevas funciones principales

Explorador de archivos

• En la 25.07 se añade la función de explorador de archivos, accesible con <space>e
• Este explorador ofrece una interfaz similar a telescope
• Facilita recorrer estructuras jerárquicas dentro de directorios y permite un control más preciso al navegar proyectos grandes

Visualización de colores de documentos vía LSP

• Ahora Helix solicita al servidor LSP información de colores del documento y muestra rangos de color RGB en línea
• Por ejemplo, con tailwindcss-language-server o vscode-css-language-server, recibe colores y permite ver cajas de color directamente dentro del código

Mejoras en el modo de comandos (:)

• Una reescritura completa del código de análisis de comandos y autocompletado corrige errores y mejora la usabilidad
• Se añade soporte para flags como --no-format en los comandos de la familia :write
• Se incorporan expansión de variables/valores dentro de comandos (%{variable_name}, %sh{comando}, etc.) y autocompletado
• La estructura se cambió a un parser extensible para manejar entradas complejas y facilitar futuras ampliaciones del sistema de comandos

Tree-house: nueva arquitectura para la integración con Tree-sitter

Qué es Tree-sitter

• Tree-sitter es un framework para generar y usar parsers rápidos y resistentes a errores
• Permite escribir reglas de parser con un DSL de gramáticas y generar y aprovechar árboles sintácticos dentro de editores y herramientas
• Por ejemplo, se usa en la exploración y resaltado de código de GitHub, en spell-check de servidores de código y en herramientas de diff
• Las consultas de Tree-sitter se usan para hacer pattern matching sobre subárboles y capturar nodos sintácticos

Integración anterior de Tree-sitter en Helix y sus problemas

• En sus inicios, Helix utilizaba el binding oficial de Rust (el crate tree-sitter) y el resaltador tree-sitter-highlight
• tree-sitter-highlight es no incremental, por lo que siempre debía volver a parsear todo el documento, causando pérdida de rendimiento y desperdicio de recursos
• Helix intentó mejorar esto con un fork propio del resaltador, pero fue volviéndose cada vez más complejo y difícil de mantener

Introducción de Tree-house y sus ventajas

• Tree-house pone el foco en una arquitectura separada de parsing y consultas, código limpio, eliminación de bugs crónicos y una estructura orientada al futuro (como parsing en paralelo)
• Su fortaleza principal es el manejo robusto de inyecciones (Injection)

Inyecciones (Injection): soporte para múltiples lenguajes y capas

• Las inyecciones funcionan, por ejemplo, cuando aparece un bloque de código Rust dentro de Markdown y solo ese rango se parsea por separado como Rust
• Incluso casos complejos, como Markdown dentro de comentarios de Rust y luego Rust dentro de bloques de código en ese Markdown, se soportan correctamente gestionando las capas como una estructura de árbol

Inyecciones incrementales

• Solo se vuelven a parsear y se vuelven a consultar rápidamente las capas donde realmente hubo cambios, usando así la mínima unidad de trabajo
• Esto maximiza la eficiencia en documentos Markdown con listas muy grandes o estructuras anidadas

Resaltado de variables locales (locals)

• Resalta correctamente variables locales, como parámetros dentro de funciones, tanto en su declaración como dentro de su alcance (scope)
• Tree-house resuelve un problema crónico donde el resaltado desaparecía si la definición quedaba fuera de la vista

Soporte globalizado para inyecciones

• En el tipo Syntax, buscar y consultar capas de inyección se vuelve posible en tiempo logarítmico (logarithmic)
• APIs como TreeCursor y QueryIter ahora pueden aplicar el conjunto completo de capas de inyección
• Esto sienta las bases para un comportamiento consistente entre límites de lenguajes, como código dentro de HTML <script> o bloques de código Markdown

Cierre

• Helix 25.07 impulsa una renovación de usabilidad con el explorador de archivos, colores en línea y mejoras en el modo de comandos/parser, y además emerge como candidato de próxima generación entre los editores de texto gracias a la nueva arquitectura basada en Tree-house
• Los detalles completos de la actualización pueden consultarse en el changelog
• La participación en la comunidad y las contribuciones pueden hacerse a través de Matrix y el repositorio de GitHub

[GN⁺]

Opiniones de Hacker News

• Helix es realmente excelente: ofrece de inmediato muchas funciones como selector de archivos, resaltado de sintaxis y linting, sin instalar plugins ni hacer configuraciones complejas, mientras que vim o neovim normalmente requieren bastante configuración desde el inicio. Me gustaría usarlo, pero su principal desventaja es que los atajos de teclado funcionan distinto a vim. Si el familiar x no borra el carácter bajo el cursor o d no queda esperando una acción, me confundo y me frustro, porque llevo mucho tiempo usando esos comportamientos de vim. Probablemente muchos usuarios de vim sientan algo parecido en este punto, y cambiar hábitos es muy difícil, sobre todo porque vim está disponible casi en cualquier entorno y no es fácil escapar de eso. Por suerte, existe un soft fork de Helix llamado evil-helix que agrega atajos de Vim, y quisiera recomendárselo a quienes tengan el mismo problema que yo. Además, Helix y evil-helix funcionan bien incluso en Windows(cmd) con solo bajar el .exe, sin necesidad de instalar rust.

  • Para mí no es que no quiera aprender algo nuevo, sino que el problema es que estos atajos no se pueden usar en otros lados. Casi todos los editores en línea y estaciones de trabajo ofrecen atajos de vim, y cuando entras por ssh a Linux es importante que siempre esté vim. Es como con el teclado QWERTY: aunque existan distribuciones mejores, no puedo renunciar a la flexibilidad de adaptarme de inmediato a casi cualquier entorno.

  • No tengo ningún problema en aprender herramientas nuevas. Usé Helix lo suficiente, pero el modelo sustantivo-verbo me pareció peor, y la retroalimentación visual también termina siendo una distracción al leer código. En vim, cosas como repetir simplemente el último comando (por ejemplo, con el atajo .) son muy cómodas, pero en Helix hay que renunciar a eso. También hay que prestar más atención al manejo del estado que en vim: en vim solo necesito cuidar mi posición actual dentro del archivo, pero en Helix también tengo que considerar dónde estaba antes. Quiero un editor con buenas configuraciones por defecto, edición modal y que no me fuerce más sincronización visual de la necesaria. Cuando hay demasiada sincronización, se pierde parte de la ventaja de tener un lenguaje de edición. Quiero concentrarme en programar, que me parece más interesante que editar en sí; un editor que exige más atención termina siendo peor como editor.

  • Cuando pasé de vim(neovim), después de casi 20 años de uso, a helix, no me costó nada, y ahora lo prefiero por mucho. Sí ajusté algunos comportamientos modales, pero lo uso siguiendo la lógica de helix. Tiene ventajas enormes como selección múltiple y LSP integrados, además de una ayuda muy potente que muestra pistas sobre acciones posibles durante entradas de varios pasos. Incluso cuando a veces me toca usar vim puro, aunque algunos mapeos mentales hayan cambiado, recuerdo los comandos básicos y me adapto rápido.

  • Helix está agregando actualmente Scheme para configuraciones programables. Cuando entre esa capacidad, parece que será posible hacer muchos ajustes finos, como repeat/transient map de emacs, seguimiento por estado y más. Gracias a la revolución de los LLMs, en un mundo donde ya es fácil tocar una octava o novena lengua, creo que van a destacar más las herramientas que permitan configuraciones detalladas.

  • Los atajos de vim eran la única razón por la que no usaba Helix. Si mediante un fork externo se puede lograr compatibilidad con vim, entonces Helix oficial también podría soportarlo si quisiera; eso me hace pensar si simplemente deciden no hacerlo a propósito.

• Me gusta muchísimo Helix. Lo recomiendo con fuerza a quienes no conectaron bien con vim o a quienes les gusta el concepto de vim pero no lograron adaptarse fácilmente. Fue mucho más fácil de aprender y usar que los vim-like tradicionales, y sus configuraciones por defecto son muy prácticas.

  • Me gusta muchísimo Helix. Honestamente, creo que si en la GUI agregaran un poco más de comodidad, como un explorador de archivos basado en mouse, podría competir con mucha fuerza contra vscode.

• Da gusto ver que un editor con capacidades tan sobresalientes siga siendo minimalista y no se enfoque en funciones inútiles de AI.

  • Discusión sobre el minimalismo de Helix: https://github.com/helix-editor/helix/issues/6187

• Felicidades; ojalá a Helix le vaya bien, pero siento que no es para mí. Yo uso Neovim y casi todo lo que quiero se puede lograr ahí, aunque tampoco estoy completamente satisfecho. El editor que quiero tendría estas condiciones:

  • Base de código moderna, reescrita completamente desde cero
  • Atajos de Vim; esta memoria muscular es muy fuerte, así que insisto en el estilo Vim. No me convence eso de que algo sea “mejor”; quiero que funcione exactamente como Vim
  • Buenos valores por defecto; Neovim tiene demasiada configuración y sus predeterminados no siempre me satisfacen
  • Basado en Treesitter; mejor aún si puede correr sobre WASM (como Zed o Neovim moderno)
  • Sistema de extensiones en Lua; JS y Scheme no me atraen mucho. Idealmente, módulos WASM con solo funciones esenciales expuestas. Quisiera una configuración de plugins con un lenguaje no Turing completo
  • TUI y GUI opcional
  • LSP, DAP, snippets, autocompletado e interfaz integrada para pruebas/debugging
  • Vista del sistema de archivos integrada, al estilo Oil.nvim
  • Búsqueda integrada al estilo Telescope/FZF-lua
  • Integración con git; también sería bienvenida una UI de git integrada tipo magit/neogit
  • Manipulación de AST basada en Treesitter y saltos con etiquetas al estilo Flash.nvim integrados
  • Macros y multicursor
  • Integración opcional de AI basada en cursor (Chat UI)

  • Yo también reconozco la memoria muscular de Vim, pero creo que mucha gente se aferra demasiado a eso. Yo he cambiado de OS, de editor y de IDE muchas veces, y durante los primeros días siempre es desesperante, frustrante y hasta te dan ganas de irte a sembrar papas, pero después de ese tiempo siempre aparece una nueva memoria muscular. Me parece una lástima renunciar a muchas otras ventajas del software solo por unos días de incomodidad.

  • No me queda claro en qué parte Helix no cumpliría con las condiciones que mencionaste. Desde mi punto de vista, Helix satisface casi todo.

  • Viendo la lista de requisitos, al final parece que lo que quieres es Neovim, pero cambiando Lua por otro lenguaje.

• Amo Helix, felicidades. El tema por defecto es bonito, la configuración inicial también es excelente, y se puede usar apenas lo instalas sin casi tocar nada. No reemplazó por completo mi IDE, pero le puse un alias a vi y también configuré $EDITOR como Helix. Cuando necesito hacer ediciones rápidas o depurar desde la CLI, termino usando Helix siempre.

• Me gustó mucho Helix y le tenía bastante simpatía, pero el comportamiento de undo no me pareció lógico; deshacía demasiadas cosas de una sola vez y se sentía poco natural. Por eso incluso llegué a perder trabajo real.

  • Hubo dos cosas de undo que me resultaron incómodas:

    • Si el contenido editado no está visible en pantalla al hacer undo, salta bien hacia esa zona, pero con la misma pulsación también hace el undo de inmediato, y eso confunde. En otros editores, si el contenido no está visible, primero solo saltan a la zona y no deshacen todavía. En Helix, cada vez que lo pulsas tienes que verificar si realmente cambió algo.
    • Undo agrupa demasiado. Aunque pases 30 minutos escribiendo en modo inserción, todo se deshace de una sola vez al cambiar de modo. Los save points hay que registrarlos manualmente. Yo intenté asignarlos a la barra espaciadora para tener un undo más fino, pero eso trae efectos secundarios, como perder la selección. No encontré una solución limpia. En general estoy satisfecho con Helix, pero sí decepciona que la profundidad de undo requiera intervención manual.

  • Undo y “repetir el último comando” sí se sienten un poco raros, pero el resto de las funciones me gustan tanto que sigo usando Helix como editor principal. Eso sí, me da curiosidad si en la parte donde perdiste trabajo ya no se podía hacer redo.

• Ojalá existiera un “modo Kakoune” en Helix. Como en el trabajo uso Windows, Kakoune no es lo ideal, y Helix parecía perfecto, pero me cuesta mucho superar los atajos de teclado. La filosofía de atajos de Helix me molesta porque es más verbosa que la simplicidad de Kakoune. Además, la configuración de atajos en Helix no es lo bastante potente como para imitar Kakoune correctamente, y eso también decepciona. Yo me pasé a Kakoune porque me cansé de las inconsistencias y comportamientos ilógicos de vim, y en ese aspecto Helix me parece un paso atrás.

• Me da risa eso de llamarlo un editor “postmoderno”; desde “shell for the 90s” de Fish shell, me parece el segundo mejor chiste. Viéndolo en video, también impresiona que sea TUI y todavía conserve un poco de vibra de Emacs TUI.

• De verdad hace falta un editor tipo vim con el nivel de integración total que tiene Helix. Las distribuciones de Neovim tienen las piezas demasiado sueltas y siempre hay algo que se siente sutilmente incómodo. También creo que la interfaz de Vim en general necesita un rediseño completo, pero me gustaría que se mantuviera el modo modal centrado en acción-objeto.

  • Evil-Helix parece encajar con ese tipo de necesidad. Todavía se ve bastante áspero, pero vale la pena revisarlo: https://github.com/usagi-flow/evil-helix

  • Me da curiosidad qué significa exactamente ese modo modal de acción-objeto.

• Me impresionó la explicación detallada sobre el resaltado de sintaxis y las capacidades de comprensión de código de Helix y editores similares. La estructura y funciones basadas en tree-sitter parecen encajar perfecto con un lenguaje de consultas, y más allá de buscar símbolos o referencias, da la impresión de que podría existir un DSL de consultas verdaderamente general. Me pregunto si algo así ya existe.

  • El editor zed usa tree-sitter y un motor de consultas potente (el DSL es Lisp Scheme). Referencia: https://zed.dev/blog/syntax-aware-editing#tree-queries