Impresiones tras cambiar de Vim a Helix

• Un desarrollador que usó Vim durante 20 años comparte su experiencia tras cambiarse al editor Helix y usarlo por 3 meses
• Helix resulta atractivo porque ofrece soporte integrado para language server (LSP) sin necesidad de configuraciones complejas
• En particular, frente a Vim/Neovim, destacan la búsqueda mejorada y los cursores múltiples, que facilitan entender el contexto entre varios archivos y hacer ediciones masivas
• Al presionar teclas, un popup de referencia rápida (quick reference) permite aprovechar atajos sin olvidarlos
• Aunque tiene algunas incomodidades, como no generar listas de Markdown automáticamente, no contar con undo persistente y sufrir crashes aproximadamente una vez por semana, la experiencia general ha sido satisfactoria
• Reaprender la memoria muscular de Vim acumulada durante 20 años fue más fácil de lo esperado, y resultó mucho más efectivo aprender la “forma de Helix” que intentar forzar la de Vim

---

Por qué cambié a Helix

• Empecé a usar Helix para poder aprovechar fácilmente su integración con language servers
  • En Vim/Neovim, configurar language servers era complicado, mientras que Helix permite usar de inmediato funciones como ir a definición o renombrar símbolos sin configuración adicional
  • Antes tenía que mantener una gran cantidad de plugins y archivos de configuración, pero con Helix esa carga se reduce gracias al soporte integrado

Principales ventajas de Helix

• La calidad de su sistema de búsqueda
  • Al buscar cadenas en todo el repositorio, muestra los resultados en una ventana de vista previa, por lo que se puede desplazar por los archivos coincidentes y ver también el código alrededor
  • A diferencia del plugin de ripgrep en Vim, los resultados ofrecen mucho más contexto, lo que permite decidir más rápido
• Referencia rápida de atajos
  • Al pulsar la tecla g, aparece como popup de ayuda una lista de comandos de movimiento disponibles, lo que resulta muy intuitivo
  • Incluso los atajos que no se usan seguido se pueden consultar fácilmente, así que la curva de aprendizaje es más suave

Diferencias entre Vim y Helix

• En lugar de la función de marks con ma y 'a, se usa Ctrl+O y Ctrl+I para seguir el historial de movimiento del cursor
• En vez de macros, se usa principalmente la edición con cursores múltiples
  • Para cambios masivos dentro de un documento: seleccionar todo con % → selección por regex con s → realizar las ediciones múltiples necesarias
  • Los cursores múltiples resultan mucho más cómodos que escribir macros cada vez
• En lugar de tabs, se puede cambiar rápido usando el buffer switcher con space + b

Incomodidades de Helix

• La función de reflow de texto es menos efectiva que gq de Vim
  • Tiene peor compatibilidad con listas
• No admite la creación automática de listas en Markdown
  • Aunque se presione "Enter" al final de un elemento de lista, la lista no continúa
  • Hay una solución parcial para listas con viñetas, pero no para listas numeradas
• La función de undo persistente todavía no está implementada
  • En Vim podía usar undofile para deshacer cambios incluso después de cerrar el editor, pero Helix todavía no tiene esa función
• No admite recarga automática de archivos
  • Después de que un archivo cambia en disco, hay que ejecutar manualmente :reload-all (:ra<tab>)
• A veces se cae
  • Aproximadamente una vez por semana, posiblemente relacionado con editar mucho Markdown
  • No es un gran problema porque basta con volver a abrirlo
• Aun así, sigo usando Helix

Proceso de cambio y experiencia de aprendizaje

• Me preocupaba que reaprender la memoria muscular de Vim acumulada durante 20 años fuera muy difícil
• Empecé a usar Helix en un proyecto personal durante vacaciones y, después de 1 o 2 semanas, ya no me resultaba confuso
• Al principio intenté forzar keybindings parecidos a Vim, pero no funcionó, y aprender la “forma de Helix” fue mucho más fácil
• Aun así, siguen existiendo algunas partes confusas
  • La definición de "palabra" en w es distinta entre Vim y Helix (en Helix incluye el espacio posterior a la palabra; en Vim no)

Entorno de edición basado en terminal

• Como durante años usé sobre todo versiones GUI de vim/neovim, usar el editor en la terminal requirió cierta adaptación
• Flujo de trabajo que finalmente elegí
  • Uso una ventana de terminal separada para cada proyecto, y todas las pestañas de esa ventana comparten el mismo directorio de trabajo
  • Coloco la pestaña de Helix como la primera pestaña de la ventana de terminal
• Como es cómodo trabajar con varios proyectos en paralelo, incluso puede ser mejor que mi flujo de trabajo anterior

Configuración

• Frente a una configuración de Neovim de cientos de líneas, mantengo una configuración muy simple
  • Básicamente solo configuré 4 atajos de teclado
• Configuración principal
  • Tema: solarized_light
  • El registro de yank por defecto se configura como + para sincronizar con el portapapeles del sistema
  • # se asigna como atajo para alternar comentarios (no me gustaba el Ctrl+C predeterminado)
  • ^ y $ se remapean para mover al inicio/final de línea (no quería aprender otra manera)
  • <space>l se asigna a :reflow (como escribo mucho texto, necesito hacer reflow con frecuencia y extrañaba el atajo gq de Vim)
• También configuro preferencias por lenguaje en un archivo languages.toml separado
  • En Python: uso el formateador black, el language server pyright y desactivo el formateo automático

Conclusión: impresiones tras 3 meses

• 3 meses no es tanto tiempo, y todavía podría volver a Vim algún día
  • En el pasado me cambié a nix y luego volví a Homebrew 8 meses después (aunque sigo usando NixOS para administrar un servidor y estoy satisfecho)
• Helix todavía no es un producto terminado, pero su dirección como “editor sin configuración” es clara
• Gracias a su simplicidad y funciones integradas, tiene potencial a largo plazo como reemplazo de Vim
• Aun así, que siga usándolo o no dependerá de futuras mejoras de estabilidad y expansión de funciones

[GN⁺]

Opiniones en Hacker News

• El editor a veces se cae por un segfault como una vez por semana, pero me llama la atención esa forma de ver la pérdida de datos como “no importa mucho, solo lo vuelves a abrir”; Helix no tiene persistent undo, así que aunque lo reabras no vuelve al estado anterior
  Llevo mucho tiempo usando Vim/Neovim, probé configuraciones propias y también hechas por otros, y aunque de verdad me gusta Vim, me resulta muy atractivo lo que ofrece Helix listo para usar sin tener que configurar nada aparte
  Pero la configuración de Helix en sí me parece bastante primitiva, así que pienso que con solo unos primeros años usando Vim probablemente ya habría podido replicar en Helix el entorno que obtengo ahí, y decir que así ya no había más infierno de configuración
  Me encanta que las ventanas emergentes de ayuda te indiquen qué ruta o keybinding debes seguir; no suelo usar tan seguido funciones como "ir a la definición" o "ir a referencias", así que se me olvidan los atajos con facilidad. Ojalá este tipo de popups contextuales se adoptara más ampliamente, y sería realmente útil si aparecieran de forma inteligente solo cuando uno duda al escribir
  • Sería increíblemente cómodo tener popups de ayuda contextual al usar combinaciones de teclas complejas en todas las apps, y mejor todavía si se mostraran de forma inteligente solo cuando la entrada se detiene
    Llevo 20 años usando Vim/Neovim, pero recién hace 6 meses instalé el plugin which-key y me ha resultado muy útil
    which-key.nvim GitHub
  • Creo que se perdió el contexto del problema de configuración en Vim
    Intenté varias veces dejar bien armado el entorno principal del servidor de lenguaje, por ejemplo para poder usar "ir a la definición", pero siempre sentí que era demasiado difícil lograr una experiencia cómoda en Vim o Neovim
  • Coincido con lo de replicar la configuración de Vim, pero es muy práctico poder instalar Helix directamente en un servidor y usarlo de inmediato
    No está la molestia de mover la configuración de Vim y sus dependencias relacionadas; el entorno de desarrollo se siente mucho más portable, aunque no tan complejo como una configuración avanzada de Vim, sino más bien básico
  • Estoy 100% de acuerdo con la función de popup de ayuda; sería muy útil verla aplicada en muchos otros lugares
    En especial, después de ver la explicación y las capturas relacionadas en ese artículo, terminé deseando muchísimo esa función
    Si el popup apareciera de forma inteligente según condiciones como un timeout, sería excelente porque no molestaría cuando no hace falta y te guiaría automáticamente solo cuando dudas
  • He usado Helix casi a diario durante 3 años, y que se caiga por segfault ha sido algo rarísimo, contadas veces; casi nunca pasa
• Estoy totalmente enganchado con Helix y lo uso para todo mi desarrollo
  Antes usaba sobre todo neovim y VS Code, pero Helix cubre una ventaja muy particular
  • El diseño es hermoso (se nota mucho cuidado en los detalles)
  • Rendimiento rápido (nunca me ha parecido lento)
  • Los keybindings por defecto se sienten muy ergonómicos
  • Puedes usarlo tal cual apenas lo instalas, sin configuración
    Me daba flojera configurar neovim o seguir usando vim, así que necesitaba algo a medio camino entre VS Code y nvim, y Helix encaja perfecto
    Si fuera un maestro de vimscript tal vez pensaría distinto, pero no lo soy, así que me va perfecto
    Ojalá Helix siga como está y no necesite volverse más modular ni más tipo UNIX
    Ya existe un ecosistema de herramientas bastante variado, y también puede usarse integrado con Claude Code (aplicando nuevas ediciones con refresh del buffer)
    Es uno de los mejores editores, así que incluso empecé a apoyar el proyecto cada mes
    Si pudiera pedir una mejora a futuro, lo que más extraño es que el editor pueda renderizar imágenes o fórmulas; espero que eso llegue mediante plugins como el protocolo de terminal Kitty o sixel
    Me sería especialmente útil al trabajar en notas o blogs en archivos Markdown
    Le deseo lo mejor a Helix
  • Una app que se puede usar justo después de instalarla, como Helix, da mucha tranquilidad porque reduce la preocupación por ataques a la supply chain
    VSCode y (neo)vim siempre me inquietaban porque hay que traer plugins desde muchos lados
  • Si necesitas algo intermedio entre nvim y vscode, surge la duda de si no bastaría con usar el plugin de vim dentro de vscode
  • A mí también me gusta helix, pero no voy a abandonar nvim
    No soy desarrollador de Lua, pero un LLM ayuda muchísimo a configurar o modificar nvim
    La principal razón por la que terminé usando helix es que la configuración de LSP/lint está muy bien resuelta
  • En vez de decir “maestro de vimscript”, en realidad la opinión es que en neovim hay que usar Lua, ¿no?
• Intenté pasarme de neovim a helix durante unas semanas, pero lo dejo registrado porque aún faltan funciones esenciales
  • acciones de código automáticas al guardar (por ejemplo, agregar imports de Go): PR #6486
  • búsqueda difusa integrada con selector de archivos tipo telescope+rg: PR #11285
  • actualización automática del buffer cuando cambia el archivo en disco: issue #1125
  • función de navegador de árbol de archivos: se rechazó introducirla como parte del sistema de plugins; aún no está implementada PR #5768 Además de eso había otras cositas menores tolerables; pienso volver a intentarlo en 1 o 2 años
  • Yo uso Helix compilando seguido desde HEAD con homebrew, y me sorprende lo que dijo Julia sobre los crashes frecuentes
    Comparto algunas cosas sobre funciones que ya fueron mergeadas en HEAD —

    acción de código al guardar: se puede resolver con hooks al guardar (sí aplica para Go), aunque podría ser difícil aplicarlo a otros lenguajes
    búsqueda difusa: está integrada desde hace mucho y recientemente mejoró bastante con un rework
    actualización automática del buffer: es una función muy necesaria si dejas el editor en segundo plano con frecuencia
    árbol de archivos: en HEAD ya se puede hacer exploración jerárquica con Space+e/E, y es algo relativamente reciente

  • El explorador de archivos enlazado se abandonó, pero a inicios de este año se hizo merge en Helix un explorador estilo vim-telescope
    Como ya hay un selector de archivos integrado basado en búsqueda difusa, un explorador de archivos tradicional no aporta tanta utilidad adicional
  • Yo también quise pasarme de neovim a helix, pero por la memoria muscular de décadas con los comandos de vim, los pequeños errores se iban acumulando y me rendí rápido
    También probé un plugin de keybindings de vim para Helix, pero solo coincidía parcialmente y eso me decepcionó más
  • Me decepciona que Helix no detecte ni recargue automáticamente el archivo cuando lo modifica un programa externo (templ, sqlc, etc.)
    Me pregunto cómo resuelven eso los usuarios experimentados de Helix
• La motivación para usar Helix vino sobre todo del proceso de configurar el servidor de lenguaje (LSP)
  Configurar de forma cómoda los servidores de lenguaje en Vim/Neovim se volvió demasiado trabajo, así que terminé cambiándome a Helix
  Pero en los últimos 5 años aparecieron distribuciones de Neovim con todo incluido, tipo “batteries included”, que permiten configurarlo muy fácilmente
  Coincido en que muchos desarrolladores no quieren perder tiempo depurando el editor; por eso creo que JetBrains es tan popular
  Aun así, cuesta un poco creer que alguien con 20 años usando Neovim nunca haya logrado armar bien un entorno LSP; me hace dudar si realmente es una experiencia honesta del autor
  • Existe el caso de alguien que usó Vim por más de 10 años sin configurar nunca LSP
    Al final, incluso para eso daba más flojera porque usar un IDE completo resultaba más cómodo, así que siempre hubo dudas con la instalación y la configuración
  • Yo también he usado vim → neovim por más de 20 años, pero cuando LSP se rompe y además dejan de funcionar los atajos, aparece una barrera psicológica fuerte: ya no dan ganas de ponerse a buscar la causa
    Me resulta muy comprensible el caso del autor
  • Me sorprende; en og o neovim no me costó nada configurar LSP
    Yo también uso una configuración muy mínima, bastante barebones, y no me pareció difícil; además Lua se siente mucho más ergonómico que vimscript
    Por eso sigo usando herramientas como ALE
    Espero que también seas feliz usando Helix
  • Esto se siente completamente extraño; ¿no lleva ya más de dos años Neovim con LSP integrado?
  • Se nota que las empresas medianas están estandarizando su tooling alrededor de vscode
    Sí se pueden usar otros editores, pero casi toda la depuración y la configuración giran alrededor de vscode, así que el ambiente empuja a recomendarlo
    La configuración de Neovim+treesitter+LSP ya funciona de forma muy fluida, aunque antes fuera difícil; hoy ya no es un gran problema
    Si la razón para pasarse a Helix es LSP, me genera dudas; no sé si en realidad el autor estaba descontento con LSP
• El modelo noun-verb (objeto-acción) de Helix me pareció fresco al principio, pero al usarlo sentí que verb-noun (acción-objeto) funciona mucho mejor
  Una de las desventajas del enfoque noun-verb es que no se puede usar el comando de repetición (.)
  En Vim puedes repetir acciones como dd.., dap.., etc., pero el modelo noun-verb lo dificulta
  Más de fondo, también aparece el problema de que faltan teclas
  Demasiadas operaciones básicas terminan usando la tecla Alt, y además no existen los modos normal/visual/insert como en vim, sino solo visual/insert
  Ni siquiera está clara la separación entre motion y objeto, así que mapear teclas se vuelve más difícil y se nota más la escasez de teclas
  • El enfoque verb-noun incluso cambia la forma de pensar
    De verdad se siente más alineado con la forma de pensar que necesitas al escribir código
• El mejor cambio reciente en nvim es mini.nvim
  Es una colección de plugins creada por echasnovski que cubre muchas necesidades con buena consistencia y documentación
  Desde nvim 0.12 (nightly), con el gestor de plugins integrado (vim.pack), basta con instalar mini.nvim y lspconfig
  • Para quien tenga curiosidad sobre mini.nvim
    sitio oficial de mini.nvim
    repositorio GitHub de mini.nvim
• No dejo de sorprenderme de lo liberador que es renunciar por completo a herramientas de editor “avanzadas” como LSP
  En neovim lo uso sin plugins, sin autocompletado, e incluso sin syntax highlighting
  Siento que esta forma de autodisciplina me lleva a escribir mejor código
  No será para todo el mundo, pero recomiendo probarlo al menos una vez
  • La opinión es que vivir sin plugins o sin autocompletado está bien, pero apagar incluso el syntax highlighting ya suena a sufrimiento innecesario
  • Yo tampoco me he cambiado por completo todavía, pero en Emacs llevo un año con el autocompletado roto y la verdad no lo extraño mucho
    Tampoco uso code actions ni goto definition, y aunque a veces sí uso errores en tiempo real, como el compilador es tan rápido, no aporta demasiado
    A veces dan ganas de apagar LSP por completo; no creo que LSP haya mejorado de forma extraordinaria mi habilidad para programar comparado con hace 20 años
    En cuanto al syntax highlighting, pienso que los temas demasiado coloridos más bien rompen la concentración y no aportan gran cosa
    Prefiero temas de un solo color o de dos colores, y ni siquiera siento necesaria la distinción de color entre nombres de variables y funciones
  • Escuché que Mitchell Hashimoto trabaja muy bien de esta manera, y eso me dio confianza en que se puede ser perfectamente productivo sin tooling moderno
    Aun así, me queda la duda de si no termina acumulando fatiga por tener que recordarlo todo, o si de verdad este enfoque produce mejor código
  • Yo también programo sin ninguna herramienta de apoyo, pero el syntax highlighting sí lo dejo siempre activado
    Los colores son una capa extra de información que hace más visibles los errores o descuidos en el código y también acelera la navegación
  • En proyectos personales sí adopto esta configuración minimalista
    Pero no de forma tan extrema: mantengo syntax highlighting y la retroalimentación de errores de sintaxis mediante LSP
    No uso autocompletado ni enlaces automáticos a documentación
• Si quieres aprender Helix, recomiendo la versión renovada de la documentación hecha por nic-revs
  helix-editor.vercel.app
  Es mucho más fácil de leer que la documentación oficial, y además tiene muchos tips/tricks, así que ayuda a mitigar desventajas de Helix como la falta de terminal integrada, además de enseñar edición eficiente y keybindings
  • Siempre me frustró la legibilidad de la documentación oficial, así que esta información se agradece muchísimo
• Las distribuciones de Neovim con demasiadas funciones extra sí llegan a molestar
  Para usuarios veteranos de vim, recomiendo kickstart (en especial el fork modular kickstart-modular.nvim)
  kickstart.nvim
  Es un punto de partida muy minimalista y excelente
  • La ventaja de kickstart es que toda la configuración está en un solo archivo
    Eso sí, como ya es grande, yo lo manejo doblando secciones con fold marker para que sea más fácil administrarlo

[qdr7h]

A veces me interesa Helix por la facilidad de cosas como configurar el LSP y los plugins, pero tengo las manos demasiado acostumbradas a vi/vim, así que no es fácil.