Cómo usar el editor Helix para desarrollar en servidores remotos

• La razón para elegir Helix como editor para desarrollo en servidores remotos es que puede usarse sin instalar decenas de plugins como Vim/Neovim, lo que reduce el riesgo de ataques a la cadena de suministro
• Mediante una configuración de integración con tmux, se complementan las carencias de Helix en explorador de archivos y funciones Git TUI, permitiendo ejecutar en ventanas emergentes el administrador de archivos yazi, lazygit y otros
• Se adaptaron atajos al estilo Vim para que tareas como seleccionar líneas, mover el cursor y borrar texto funcionen de forma similar a Vim, y se cambió ESC para reiniciar cursores múltiples
• Se agregó al statusline información como la rama de Git, la codificación y la posición para mejorar la productividad
• Aprovechando inyecciones de Tree-sitter, se aplicó resaltado de sintaxis a consultas SQL dentro de Python/Go y a bloques de código en Markdown, mejorando la legibilidad
• Se elevó la productividad y el nivel de personalización con configuraciones avanzadas como LSP, guardado automático y modos de color

---

Motivos para elegir Helix

• Debido al reciente aumento de los ataques a la cadena de suministro y a los problemas de dependencia de plugins, se adoptó Helix en lugar de Vim/Neovim como editor para desarrollo en servidores remotos
• Su principal ventaja es que puede usarse solo con las funciones base, sin necesidad de decenas de plugins de Neovim
• Tras cambiar a Helix, se realizó un trabajo de personalización de la configuración para reproducir lo más posible la experiencia familiar de Neovim
• El objetivo es compartirlo para ahorrar tiempo a otros usuarios

Configuración de Tmux

• Se usa Tmux como multiplexor de terminal y, para resolver la falta de administrador de archivos y Git TUI, se añadieron atajos personalizados
• Como Helix no permite editar archivos desde el explorador de archivos, resultaba incómodo moverse rápido entre varios archivos
• Se añadieron los siguientes atajos al archivo de configuración de Tmux
  • prefix - y: ejecuta el administrador de archivos Yazi en una ventana emergente (95% del tamaño de la pantalla)
  • prefix - g: ejecuta Lazygit en una ventana emergente
  • prefix - e: abre el historial de salida de Tmux en el editor Helix para buscar y copiar
• El prefix predeterminado es Ctrl + b, pero se cambió a Ctrl + \\
• Resulta útil para trabajar con salida de terminal, especialmente al copiar a Slack la salida del cliente de ClickHouse (CSV/JSON)
  • Permite copiar directamente en vez de exportar a un archivo, reduciendo pasos
  • También podría hacerse con el mouse, pero como el scroll del búfer de Tmux es incómodo, procesarlo en el editor es más eficiente
• Yazi y Lazygit normalmente se muestran como una superposición sobre el editor Helix

Adaptación de atajos de Vim

• Aunque ya se dominan los atajos de Helix, todavía se siguen adaptando algunos atajos de Vim
• Atajos en modo Select
  • 0: ir al inicio de la línea
  • $: ir al final de la línea
  • ^: ir al primer carácter que no sea espacio en blanco
  • G: ir al final del archivo
  • D: seleccionar hasta el final de la línea, borrar y cambiar a modo normal
  • k/j: seleccionar la línea completa arriba/abajo (el comportamiento predeterminado de Helix es una selección parcial y resulta incómodo)
• Atajos en modo Normal
  • D: borra todo el texto a la derecha del cursor (se adaptó porque en Helix requiere demasiadas teclas)
  • V: cambia a modo Select y selecciona la línea completa
  • ESC: reinicia cursores múltiples (el valor predeterminado de Helix es la coma, lo cual resulta incómodo)
• Como no convencía la forma en que Helix selecciona líneas en el modo visual, se cambió al estilo de Vim
  • Se configuró para que al moverse hacia arriba o abajo se seleccione la línea completa

Barra de estado mejorada

• A la barra de estado predeterminada le falta información importante, como la rama actual de Git
• Configuración de la barra de estado
  • Izquierda: modo, spinner, control de versiones, nombre de archivo, indicador de solo lectura, indicador de modificación
  • Centro: vacío
  • Derecha: diagnósticos, diagnósticos del espacio de trabajo, ubicación, total de líneas, porcentaje de posición, codificación del archivo, formato de fin de línea, tipo de archivo, registro, cantidad de selecciones
  • Separador: se usa el carácter │
• Permite entender de un vistazo el estado del trabajo

Atajos útiles

• Los atajos personalizados mejoran mucho la eficiencia de trabajo, aunque tomó tiempo descubrirlos
• Las funciones más útiles: recargar archivo, alternar soft wrap, deshacer en Git, Git blame y Git diff
• Lista completa de atajos personalizados
  • space - e - w: guardar el búfer actual como archivo
  • space - e - c: cerrar el búfer actual
  • space - e - x: cerrar todos los demás búferes (útil cuando hay decenas abiertos)
  • space - e - l: alternar inlay type hints (útil, pero siempre visibles generan mucho ruido)
  • + - f: formatear el archivo actual
  • + - w: renderizar caracteres en blanco (para revisar caracteres invisibles dentro del documento)
  • + - W: desactivar la renderización de caracteres en blanco
  • space - f - .: mostrar/ocultar archivos ignorados por Git en el selector de archivos
  • space - f - r: recargar todos los archivos (muy útil porque Helix no soporta recarga automática; sirve para cambios externos o actualizar el gutter tras un commit)
  • space - f - x: deshacer el cambio de Git en la posición actual del cursor
  • space - f - w: mostrar Git blame de la línea actual
  • space - f - d: mostrar Git diff

Configuración del editor

• Después de 6 meses de uso, se descubrió que existe una función de guardado automático al cambiar de pestaña de terminal
• Algunas funciones recientes de Helix están desactivadas por defecto, para evitar que usuarios existentes se topen con cambios inesperados
• Para descubrir funciones nuevas, hay que revisar manualmente cada opción
• Opciones principales de configuración
  • line-number = "relative": mostrar números de línea relativos
  • rulers = [120]: configurar una regla vertical visual (útil cuando se limita la longitud máxima de línea sin autoformato)
  • true-color = true: forzar soporte de true color
  • completion-replace = true: el autocompletado reemplaza la palabra completa
  • trim-trailing-whitespace = true: eliminar espacios finales
  • color-modes = true: diferenciar visualmente los modos por color
  • rainbow-brackets = true: usar distintos colores para paréntesis anidados (función reciente, aún sin lanzamiento oficial)
  • editor.file-picker.hidden = false: mostrar archivos ocultos (dot files) en el selector de archivos
  • editor.indent-guides.render = true: agregar guías visuales de indentación
  • editor.inline-diagnostics.cursor-line = "warning": mejorar la visualización de diagnósticos (ver captura)
  • editor.auto-save.focus-lost = true: guardar automáticamente al perder el foco (requiere soporte de la terminal)
  • editor.auto-save.after-delay.enable = true: guardar automáticamente tras un retraso definido (configurado en 300 segundos)

Ajustes de LSP

• Se añadió harper-ls como LSP para todos los lenguajes, con el fin de resaltar errores gramaticales dentro de comentarios

Inyecciones personalizadas de Tree-sitter

• Helix permite definir inyecciones personalizadas de Tree-sitter, lo que hace posible resaltar un lenguaje dentro de otro
• Casos de uso
  • Resaltado de sintaxis para consultas SQL dentro de Python y Go
  • Resaltado de YAML front matter y bloques de código en Markdown
  • También puede usarse para resaltar snippets de HTML
• Se subieron a GitHub los archivos de configuración para compartir las inyecciones personalizadas y la configuración

• Helix es un editor de terminal de nueva generación cuyas fortalezas más destacadas son la minimización de plugins, la seguridad y la personalización intuitiva

[xguru]

Un desarrollador que ha usado Vim durante 20 años comparte su experiencia de cambiar de Vim a Helix

[GN⁺]

Opinión en Hacker News

• Últimamente he estado reconstruyendo mi configuración del editor. Llevo 20 años usando Emacs y 15 usando Vim en paralelo, y no puedo elegir solo uno. Mi objetivo es ver qué tan rápido puedo armar una configuración lo bastante completa como para usarla de inmediato en trabajo de software Python de nivel enterprise. Esta vez, en particular, estoy intentando reducir al máximo la dependencia de extensiones de terceros y quedarme solo con lo necesario. Mi configuración actual de Neovim me parece la mejor que he tenido, pero terminé usando más plugins de los que esperaba. En el caso de Emacs, todavía estoy en una etapa temprana, pero me parece interesante cuánto ha mejorado, al punto de que en la versión 30 o superior la necesidad de plugins de terceros se reduce bastante. Antes usaba lsp-mode, pero ahora estoy satisfecho con Eglot. El completion preview mode tampoco reemplaza por completo a corfu, pero está bastante bien. Mi lista de plugins imprescindibles en Emacs es Magit, Expreg(teeesitter expand region), Multiple cursors y dape(depurar con integración de Eglot). Probablemente también agregue Consult y orderless. Mi configuración de Neovim se puede ver aquí

  • El nuevo nvim también está reduciendo cada vez más la necesidad de plugins. Ya trae gestor de plugins integrado, visor de diff y lsp

  • ¡Estás administrando bastantes plugins de nvim! La semana pasada reescribí mi configuración de nvim con 4 plugins, incluyendo mini.nvim. Sentí que cuando le agregas muchos plugins, la estabilidad y confiabilidad de nvim caen bastante. En Emacs solo necesitar 2 me da envidia, y seguro así funciona mucho más estable. Mi configuración se puede ver aquí

  • Me pregunto si, incluso después de usarlo unos meses, crees que se puede llegar a algo comparable a la configuración incluida por defecto de Pycharm+IdeaVIM. Claro, también está la diversión de tocar la configuración uno mismo, pero si solo te enfocas en usar un IDE de forma eficiente, invertir tanto tiempo en configurar Neovim no suena muy eficiente

  • Expreg(teeesitter expand region) me recuerda a combobulate(aún no lo he usado, pero se ve genial). Aun así, Expreg da la impresión de ser mucho más simple y ligero

  • De verdad me da mucha curiosidad escuchar a usuarios veteranos de Emacs. Quiero saber cómo lo comparan con Helix/Vim. La gente que dice que Helix/Vim le gustó al probarlo por primera vez me da la impresión de que habla sin conocer el verdadero valor de usar Emacs por mucho tiempo. Es cierto que las teclas estilo Vim y los modos parecen estar mejor integrados en los editores modernos, pero cuando intenté usarlo, me faltó paciencia para aguantar hasta que mis dedos se acostumbraran. Me gustaría leer la experiencia de cambio de un usuario realmente hardcore de Emacs

• Yo cambié de Emacs → VS Code → Helix. Hasta ahora he intentado aprender al máximo los keybindings existentes y usarlo de forma efectiva casi sin tocar la configuración. Como me cuesta memorizar todo lo que Helix puede hacer, hice un deskmat para tener las teclas impresas sobre el escritorio. Supongo que solo al imprimirlo y usarlo de verdad sabré cuánto ayuda. Mi deskmat se puede ver aquí

  • Me pregunto cuánto tiempo usaste Emacs

• He usado Emacs como editor principal durante los últimos 10 años, y antes usaba Sublime Text. Para edición simple de archivos o en servidores remotos a veces uso Vim, pero nunca sentí la necesidad de usar exclusivamente Vim. En Emacs armé mi propio entorno a la medida creando módulos y funciones personales. Probé Helix el mes pasado y empezar fue sorprendentemente simple. También me adapté rápido al uso básico—moverme, buscar, pegar, cambiar entre buffers y ventanas—. No sé mucho sobre la historia de Helix, pero el diseño es excelente. La búsqueda global es especialmente buena, la integración con lsp funciona justo como debe, y la velocidad es realmente impresionante. Se siente muy agradable que los valores por defecto estén definidos de forma consistente y útil. Planeo seguir usándolo para familiarizarme más; Emacs sigue siendo mi editor por defecto, pero Helix es tan rápido que podría convertirse en mi editor principal para escribir código

• Estoy probando Helix por primera vez, y siento con fuerza dos desventajas

  • La edición modal es la base, pero con Vim puedes usar esa muscle memory tal cual en casi cualquier parte (el modo Vim existe en casi todos lados, hay muchas extensiones como Vimium, y si estás en un entorno ssh casi seguro hay Vim)
  • Helix apunta a la simplicidad, así que no tiene integración de terminal ni mucha extensibilidad por plugins (incluso el lint solo se soporta vía lsp), y esa combinación parece una limitación porque implica que tienes que montar una configuración aparte por encima del editor (usar tmux, etc.) No lo digo para atacar sus puntos débiles, sino porque quiero entender qué ventajas compensan eso

  • No entiendo bien por qué LSP sería una desventaja. Da la impresión de que LSP corre como proceso separado, y más bien me parece bueno para aislar plugins. De hecho, podría funcionar incluso mejor que los plugins tradicionales de editores. Tampoco siento la falta de integración con tmux; aunque uso Emacs como principal, casi nunca uso el terminal interno. Si solo hay que mover la muscle memory, un editor rápido hecho en Rust ya me parece suficientemente convincente

  • Se suele decir que las motions de Vim, una vez aprendidas como muscle memory, se pueden usar en cualquier parte, pero en la práctica casi ningún desarrollador quiere usar el entorno básico de Vim tal cual, sin plugins ni configuración. La mayoría quiere un editor ajustado con detalle a su propia configuración y funciones. La excepción sería alguien que de verdad entra por ssh a muchas máquinas distintas y necesita sí o sí el entorno básico del editor. Mencionaste la simplicidad de Helix y sus límites en plugins; originalmente Helix apuntaba a ser un editor todo en uno, pero como la comunidad no lo quiso así, se está desarrollando un sistema de plugins. No está incluido en el release principal, pero en una rama aparte ya hay varios plugins creados y en uso. Me parece correcto retrasar el release hasta que el sistema de plugins sea lo bastante estable. La mayor ventaja de Helix es que mejoró la UX incómoda que todavía queda en vi/vim/neovim. Es decir, cambia el orden de trabajo para que puedas ver fácilmente los cambios antes de confirmar la acción, reduciendo efectos secundarios no intencionales

• Con una configuración así, me parece que simplemente sería mejor usar vim. Estás tratando de reproducir funciones de vim dentro de Helix, y Helix también tiene muchas dependencias internamente(aunque no se vean en la superficie como en nvim). Mi configuración de vim8 se ha mantenido simple por más de 8 años. Uso vim8 porque es la versión incluida en distribuciones LTS. Solo tengo un plugin que carga automáticamente(vim-tmux-navigator, para moverme fácil entre splits de vim y de tmux), revisé el código y no lo actualizo. Dos plugins "opcionales" los activo cuando hace falta con :packadd! usando el gestor de paquetes integrado de vim. Solo uso ale(lsp, diagnósticos, autoformato al guardar) y vim-fugitive(integración con git). ale no tiene dependencias. vim-fugitive se instala una vez y listo. La razón de no cargar plugins automáticamente es que vim suele usarse sobre todo para edición rápida, y solo activo git/lsp en proyectos largos. No hace falta usar plugins innecesarios

  • A mí también me gusta Neovim moderno, así que estoy resolviendo ese problema creando un paquete de Python(sobre todo pensado para quienes ya están en el ecosistema Python o usan uv o pipx). Puedes instalar el Neovim más reciente con uv tool install binwheels-neovim o pipx install binwheels-neovim, y funciona de inmediato en Windows, mac y Linux. Este paquete envuelve los releases oficiales de Neovim y usa uv o pipx para traer el binario correspondiente al sistema operativo y arquitectura. En Linux, como se necesita compatibilidad con GLIBC más viejo que el de los releases oficiales, lo compilo aparte y lo ofrezco así. Puedes ver más en PyPI, Github principal y log de compilación

  • Helix tiene una superficie de ataque de supply chain muchísimo menor que nvim+plugins. Todo se gestiona dentro del propio Helix, así que es mucho más seguro que nvim, donde cada plugin tiene su propio proveedor. Además, los releases de Helix avanzan de forma lenta y cuidadosa, de modo que incluso si aparece una vulnerabilidad no se vuelve un gran problema

  • El modelo de edición de Helix es superior

• Si necesitas un TUI mientras usas Helix, me pregunto por qué elegirlo en vez de neovim. Me gustan los valores por defecto de Helix, pero siento que llega un punto donde, si necesitas cambiar algo, todo empieza a volverse más molesto. Y si quieres una "experiencia IDE completa" con Helix, tampoco entiendo por qué no usar Zed, VSC o un IDE de JetBrains. Yo, si necesito algo simple, uso nvim; si necesito más funciones, abro WebStorm o lo uso junto con un colega cuando hay que buscar algo

  • Cuando trabajas por ssh en hardware modesto, Helix arranca casi al instante. Armar la misma funcionalidad con nvim lo vuelve más lento, y el costo de mantener configuración/actualizaciones de plugins es mayor. Además conozco Rust, así que también puedo contribuir corrigiendo bugs. No sé lenguajes de la familia C, así que prefiero proyectos open source hechos en lenguajes que sí conozco. Soy un hobby coder que usó n/vim durante 12 años y en los últimos 2 se pasó a Helix. La verdad hay varias cosas de nvim que extraño y que se sienten más naturales, pero Helix de verdad "arranca al instante" y esa comodidad termina ganándole a todo

  • En los últimos años usé neovim, helix, emacs y nano durante bastante tiempo cada uno, y la experiencia out-of-the-box de Helix fue por mucho la mejor. Los valores por defecto están muy bien elegidos, y la ayuda contextual y las pistas aparecen tan bien que no importa si olvidas comandos de uso frecuente, y también es fácil encontrar los que usas rara vez. Además, en mi cabeza el orden en que funcionan los comandos de helix se siente más natural que en vim. Los editores modernos como nvim/spacemacs tienen una barrera demasiado alta de plugins/configuración. Gracias al ecosistema de plugins pueden hacer cosas que Helix todavía no puede(por ejemplo, emacs puede usarse como IDE para cualquier lenguaje lisp y helix no puede cargar un repl), pero a cambio no solo tienes que aprender el editor, sino también una infinidad de plugins, y aunque busques respuestas, cada una cambia según la versión y la combinación, lo que confunde mucho. Al crear algo nuevo, al final terminas confiando en recomendaciones ajenas o invirtiendo tiempo extra en probar y aprender por tu cuenta. Helix, al ser un proyecto nuevo, no carga con el peso de decisiones antiguas y puede adoptar decisiones y valores por defecto alineados con patrones modernos de desarrollo. No es perfecto, pero si alguien es principiante en TUI y quiere algo usable ya mismo y fácil de empezar sin configuración, recomendaría helix

  • hx es rápido tanto al arrancar como al ejecutarse, y además se ve bonito. Los valores por defecto me dejaron bastante satisfecho, así que solo hice pequeños ajustes, y a diferencia de emacs/neovim donde vivía atrapado en un endless improvement loop, con hx sí se ve un final. TUI también funciona bien en servidores remotos, así que uso el mismo entorno en mac, linux y servidores(aunque otros editores también lo permiten, hx también lo soporta bien). Todos los lsp que necesito funcionan sin problema, y aunque configurar languages.toml fue un poco molesto, con otros editores me pasó lo mismo

  • Me gusta la configuración simple y el selection-first editing model. Como referencia, puedes ver aquí. Hablando con gente a la que le cuesta adaptarse a Vim, me di cuenta de que yo ya estaba acostumbrado al modelo de "seleccionar primero" como Helix. Me costó adaptarme a operaciones como en Vim donde no ves el texto objetivo hasta después del comando(cuando el alcance del efecto se muestra después)

  • Elegir editor no es una decisión tan racional; pesan mucho más factores psicológicos como el gusto personal, la novedad o la diversión

• No conocía el comando :reset-diff-change. Yo siempre había usado checkout -p en git, pero hacerlo directamente dentro de Helix es mucho más cómodo

• Probé Helix, me adapté con esfuerzo y ahora ya lo uso con soltura. Pero terminé dándome cuenta de que este "flujo de trabajo en orden inverso", aunque es fácil de aprender y de implementar, en la práctica me hace más lento. Así que al final volví a Vim, y luego a Zed(modo Vim)

• Hoy probé Helix por primera vez, y de verdad es un editor muy bien diseñado. Aun así, eché de menos atajos rápidos de Vim como y2$, dw

  • En realidad no es que falten atajos, sino que y2$ se escribe como 2xy y dw como wd

• Todavía no encuentro cómo borrar la línea actual incluyendo líneas vacías en Helix. xd borra una línea cuando no está vacía, pero si la línea está vacía termina borrando dos líneas a la vez

  • x selecciona la línea actual, y si ya está seleccionada, extiende a la siguiente. X extiende la selección a los límites de línea(selección por línea). Usa X

  • En una línea vacía simplemente usa d

  • Es incómodamente molesto. Yo también estoy usando un fork trivial donde cambié el comportamiento de x para que sea distinto en líneas vacías. Más detalles en este PR