Helix: editor de texto posmoderno

• Helix es un editor de texto modal basado en terminal, un proyecto open source que integra funciones modernas
• Mediante la integración con Tree-sitter, ofrece funciones de edición con reconocimiento de sintaxis como resaltado de sintaxis, cálculo de sangría y navegación de código
• Es compatible con Language Server Protocol, lo que habilita funciones de nivel IDE como autocompletado, ir a la definición, ver documentación y diagnósticos
• Está escrito en Rust, funciona sin Electron ni JavaScript, y puede usarse de forma eficiente en entornos de SSH, tmux y terminal
• El sistema de plugins y el frontend GUI están previstos para desarrollos futuros, y se caracteriza por una base de código ligera y configuraciones modernas por defecto

---

Características principales

• Helix usa como unidad central de edición un sistema de selección múltiple y cursores inspirado en Kakoune
  • Los comandos pueden manipular varias selecciones al mismo tiempo, lo que permite edición de código en paralelo
• Utiliza Tree-sitter para generar árboles sintácticos tolerantes a errores
  • Gracias a esto, admite resaltado de sintaxis preciso, sangría automática y navegación de código

Funciones de manipulación y navegación de código

• Ofrece selección y desplazamiento por nodos del árbol sintáctico como funciones, clases y comentarios
  • Esto permite editar con base en la estructura sintáctica y no solo en texto plano
• A través de Language Server Protocol (LSP) ofrece autocompletado, ir a la definición, ver documentación y diagnósticos según el lenguaje
  • Permite aprovechar funciones de nivel IDE en la terminal sin configuración adicional

Base técnica

• Está escrito en Rust, lo que garantiza estabilidad y rendimiento
  • No usa Electron, VimScript ni JavaScript
  • Puede ejecutarse en entornos de SSH, tmux y terminal convencionales
  • Su estructura liviana mejora la eficiencia de batería

Funciones modernas integradas

• Incluye fuzzy finder para explorar archivos y símbolos, además de búsqueda global en el proyecto
• Integra varias funciones de conveniencia como cierre automático de paréntesis, integración de surround y personalización de temas
• Tiene una estructura con funciones básicas ampliamente integradas incluso sin plugins adicionales

Preguntas frecuentes

• La expresión “posmoderno” tiene un sentido de broma: si Neovim es un “Vim moderno”, Helix sería la generación posterior
• El frontend GUI está previsto a futuro como un prototipo basado en WebGPU
• Actualmente el sistema de plugins no está implementado, aunque hay planes para incorporarlo más adelante
• La diferencia frente a Kakoune es que Helix incluye más funciones de forma nativa y usa análisis de código basado en Tree-sitter
• A diferencia de Vim, Helix fue diseñado desde cero, tiene una base de código pequeña y ofrece valores predeterminados modernos con mínima necesidad de ajustar archivos de configuración

Comunidad y participación

• Se puede contribuir al código en GitHub
• Las discusiones del proyecto se realizan en el canal de Matrix
• Es posible apoyar el desarrollo a través de OpenCollective

[GN⁺]

Comentarios de Hacker News

• Me llamó la atención el chiste de “¡¿Post-modern?!”
  Muchos ingenieros entienden ‘postmodern’ simplemente como la siguiente etapa de modern, pero eso es distinto de su significado original en arte y humanidades
  Obviamente este uso no es un gran problema, pero aun así resaltó porque esperaba una creatividad realmente ‘posmoderna’

  • Se decía que Thiel y Luckey malinterpretaron a Tolkien; me gustaría ver ejemplos concretos
  • Yo pensé lo mismo cuando vi por primera vez el chiste de Helix
    Pero como ‘postmodernism’ surgió originalmente como una reacción posterior al modernismo, tampoco me parece del todo incorrecto interpretarlo como “después de modern”
    Solo que con el tiempo su significado se volvió mucho más complejo, y ahora también da risa que suene como algo “dated af”
    “Helix, el primer editor que no cree en los grandes relatos. Helix, el editor relativista. Helix, con las últimas actualizaciones de Foucault y Derrida”
  • Todo esto es culpa de Perl. Ellos empezaron esta clase de nomenclatura

• Llevo años usando Helix como editor principal (Sublime → Atom → Vim → Helix)
  La mayoría de los LSP funcionan casi sin configuración, y el archivo de configuración también es mucho más simple que el viejo .vimrc
  Solo me tomó unos días cambiar la memoria muscular de Vim, pero todavía tengo sentimientos encontrados respecto a los editores modales
  Sigo esperando la función de plegado de código

  • Como alguien que usa Emacs y Vim en paralelo, me da curiosidad qué te incomoda de la edición modal
    En Emacs uso multiple cursors y plugins basados en treesitter, así que también se puede editar de forma muy potente sin ser modal
    Me pregunto si el modo modal de Helix te resulta incómodo por una razón parecida
  • Mi queja sigue siendo la tecla Escape
    En los teclados Unix antiguos estaba cerca de la fila de inicio, pero ahora queda demasiado lejos
    Como la mayoría de los tutoriales ni menciona teclas alternativas, no entiendo cómo más de la mitad de los usuarios sigue usando Escape tal cual

• Volví a probar Helix hace unos días, y aunque está bien que la IA solo se pueda usar a través del LSP,
  que no haya recarga automática cuando los archivos cambian externamente me resultó demasiado incómodo
  Te hace estar preocupado todo el tiempo por si el archivo que modificó la IA está realmente actualizado

  • GitHub Copilot, Claude Code y Codex modifican archivos directamente mediante la API del IDE y también ofrecen una vista diff
    Ese enfoque me parece mucho más estable y atractivo
    En cambio, algunas herramientas de IA dicen que “no hace falta un IDE” y se van por un enfoque centrado en CLI, pero eso me parece una completa tontería
  • No es una solución perfecta, pero Helix tiene los comandos :reload y :reload-all
    Yo tengo reload-all asignado a Ctrl-r
  • Se puede resolver con un parche simple → enlace al PR de GitHub
  • A mí me pasó lo mismo, así que cambié mi flujo de trabajo para vigilar cambios de archivos con lazygit y editar solo desde Helix
    Otra opción es mux, que te permite comentar cambios sugeridos por un LLM por línea o por bloque (todavía está en una etapa temprana)
  • Con el tiempo, de hecho, terminé prefiriendo que no tenga recarga automática
    Cuando trabajo con Claude Code, me gusta que los archivos no cambien solos

• Vim es C, Helix es C++ y Ki Editor se siente como Rust
  Helix heredó muchas ideas de Vim, pero le falta consistencia en los atajos de teclado y también es más débil en su combinación conceptual
  Por ejemplo, en los buffers te mueves con k, pero en el explorador de archivos tienes que usar ctrl+n

  • Me da curiosidad por qué Ki se siente como Rust. A mí Helix también me parece un editor bastante elegante
  • Me sorprende escuchar que Helix ya tiene explorador de archivos. Justamente no lo usaba porque no lo tenía
  • En Vim pasa algo parecido. En la ventana de autocompletado, k se usa como carácter de entrada, así que hay que usar otra tecla
    Supongo que en Helix será por la misma razón
  • No me convence la idea de bindings basados en la posición física de las teclas
    Me pregunto qué pasa si te conectas por SSH y el teclado tiene otra distribución
  • Decir que “Helix es C++” suena como una analogía exagerada. Si Vim es C, entonces Neovim está más cerca de C++

• De verdad quería que Helix me encantara
  Tiene una configuración por defecto muy bien lograda y hasta dejé a propósito algunos hábitos de Vim para aprenderlo,
  pero al final llegué a la conclusión de que sus atajos son compromisos hechos para simplificar la implementación
  Ahora volví a usar Neovim para cambios pequeños y Zed (modo vim) para trabajos grandes

  • ¿Probaste Ki Editor? Desde el punto de vista de UX, es un modelo más avanzado que Helix
  • Como usuario veterano de Vim, me incomodó el diseño excesivamente opinado de Helix
    Por ejemplo, cuando vuelves a abrir un archivo no regresa a la posición anterior del cursor
    Podía corregirlo con un LLM, pero al final no quería mantener un fork de Helix
  • También existe evil-helix, una versión con bindings de Vim. Vale la pena probarla
  • La razón por la que terminé dejándolo fue justamente que los bindings son distintos a los de Vim
    Es realmente difícil abandonar la memoria muscular acumulada durante años
  • No estoy de acuerdo con que la UI de Helix no sea simple
    A mí la combinación hx + Zed me parece bastante buena

• Como Helix no soporta actualizaciones de archivos en vivo, resulta incómodo usarlo junto con agentes de código

• Recomiendo ver la segunda pregunta del FAQ de Helix
  Me impresionó que el LSP de Python funcionara de inmediato sin configuración
  Pero por los 25 años de memoria muscular acumulada con Vim, las diferencias sutiles de Helix me confunden demasiado
  Al final, el problema no es Helix sino mi memoria muscular

  • Después de usar durante mucho tiempo un teclado ergonómico, volver a uno normal fue difícil al principio, pero al final te acostumbras a ambos
    Creo que con Vim y Helix podría pasar lo mismo
  • En Emacs, si asignas M-ESC ESC a un comando inofensivo, puedes evitar el problema de que se cierre la ventana
    Ejemplo: (global-set-key (kbd "M-ESC ESC") 'keyboard-quit)
  • ¿Has probado el modo Evil de Emacs? Pude pasar desde Vim casi sin fricción
  • Yo también usé Vim durante 25 años, pero terminé cambiándome por completo a Helix
    Una vez que te acostumbras a diferencias como dd y G, cada vez te gusta más
  • Zed mantiene la filosofía de Helix (soporte LSP por defecto) y al mismo tiempo ofrece bindings vi exactos

• He usado Helix como editor predeterminado durante los últimos años
  Me gustan especialmente su simplicidad, velocidad, navegación centrada en el teclado y la integración con el LSP de Elixir

• He desplegado mucho código usando Helix como principal
  Mi archivo de configuración no llega ni a 50 líneas y solo agregué algunas teclas de Vim
  Puedo alternar entre Vim y Helix sin grandes problemas
  Mi configuración está aquí

• Hice directamente una extensión de modo modal para VS Code, y el enfoque de Kakoune y Helix me pareció interesante
  La estructura de “mostrar por adelantado la parte que va a cambiar” y el diseño centrado en múltiples cursores me parecieron razonables
  Pero después de unas semanas terminé volviendo al estilo clásico de Vim
  El enfoque de múltiples cursores solo me resultaba útil cuando podía ver en pantalla todos los cambios a la vez
  Hoy, gracias a la IA, escribo más texto que código, así que siento que el valor de ese estilo de edición ha disminuido

  • En Emacs existe el comando mc-hide-unmatched-lines, que permite mostrar solo las líneas donde hay cursores
    Los múltiples cursores van bien para ediciones cortas y simples, pero para cambios complejos las herramientas de edición por lotes son más eficientes
  • La función Reveal Cursors de Ki Editor
    fue creada para resolver el problema de los cursores fuera de pantalla
  • El simple hecho de poder “ver todos los cambios de un vistazo” ya me parece una ganancia neta frente al enfoque tradicional