Una carta de amor a Neovim

• Neovim hace que la edición de código no se trate de teclear rápido, sino de un bucle repetitivo de moverse, cambiar, borrar, reorganizar y revisar pruebas
• La gramática de edición de Vim reduce la fricción en la edición repetitiva al combinar operaciones sobre unidades con significado, como ci", dap, ., macros y objetos de texto
• Neovim no impone explorador, terminal ni paneles de Git, sino que deja al usuario elegir alrededor de los buffers con herramientas como Telescope, Fugitive o LSP
• La configuración puede ser tuya en archivos guardados en Git y seguir siendo parte del sistema, funcionando junto con el shell, tmux, ripgrep, git y language servers
• Se modernizó con Lua, LSP integrado, Treesitter y Lazy.nvim, pero su valor central es que lo que aprendes se acumula durante años y tu flujo de trabajo evoluciona directamente

---

La sensación de trabajo que va de Vim a Neovim

• El uso de Vim comenzó en 2011, y al principio copiaba .vimrc sin entender bien por qué j no escribía una letra sino que movía el cursor
• La primera semana fue dura y el primer mes se sintió extraño, pero una vez que el modelo de Vim se volvió familiar, otros editores empezaron a sentirse como si hubiera una capa amortiguadora entre el código y el usuario
• Probé varios editores como VS Code, los IDE de JetBrains, Sublime, Atom y Zed; las herramientas de JetBrains son muy potentes, y VS Code triunfó porque es suficientemente bueno para casi todos y fácil de extender
• Aun así, sigo usando Neovim porque se adapta a mi forma de trabajar y apoya de manera directa el bucle repetitivo de editar código

Tratar la edición no como atajos, sino como un lenguaje

• Editar código no consiste en escribir rápido, sino que se parece más a repetir tareas de moverse, hacer pequeños cambios, borrar abstracciones equivocadas, reorganizar funciones, mover archivos y revisar pruebas y diagnósticos
• La mayoría de los editores tratan el texto como un documento y el teclado como un dispositivo de entrada, pero Vim trata la edición como una gramática
• ci" cambia el contenido dentro de comillas, dap borra un párrafo y . repite el último cambio
• Las macros permiten enseñar una pequeña rutina una vez para repetirla en todo un archivo, y los objetos de texto permiten aplicar operaciones sobre unidades con significado en vez de contar caracteres
• Cuando la gramática de Vim ya está en las manos, disminuye la necesidad de arrastrar código con el mouse, hacer clic en barras laterales o abrir la paleta de comandos para tareas que repites decenas de veces al día
• Las tareas frecuentes se convierten en movimientos pequeños y directos, y también disminuye el ruido del editor

Neovim no impone tu flujo de trabajo

• Los editores centrados en GUI suelen tener una visión fija sobre dónde y cómo deben estar el explorador, la terminal, los paneles de Git y el depurador, y con el tiempo el editor acaba pareciendo una cabina de mando
• Neovim empieza con buffers, y el usuario decide qué poner alrededor
• Si necesitas un árbol de archivos, puedes añadirlo; para búsqueda difusa puedes elegir la herramienta que más te convenga, como Telescope o fzf-lua
• Para integración con Git puedes usar Fugitive, y LSP, diagnósticos, formateo, snippets, Treesitter, ejecutores de pruebas y autocompletado pueden resolverse sin convertirse en un dashboard lento de Electron
• La velocidad no es solo cuestión del tiempo de arranque, sino de confianza
  • al presionar una tecla, debe responder de inmediato
  • al abrir archivos grandes, toda la interfaz no debería quedarse congelada
  • esa misma sensación de editor de uso diario debe mantenerse al conectarte por SSH, emparejar con tmux o editar en una ventana de terminal pequeña
• Ya sea en un proyecto local, un servidor remoto, un cambio rápido de configuración, una gran app de Rails, un pequeño script de shell o al escribir en Markdown, puedes usar los mismos movimientos, los mismos comandos y la misma memoria muscular
• Esa consistencia se acumula a lo largo de toda una carrera

Configuración que puedes poseer y una herramienta que sigue siendo parte del sistema

• La configuración de Neovim son archivos dentro de Git, así que puedes leerlos tú mismo, romperlos y borrar la mitad cuando te das cuenta de que no necesitas cierto plugin
• No dependes de bases de datos misteriosas de configuración, de estados de cuenta sincronizados que solo entiendes a medias, ni de extensiones que se comportan raro en segundo plano por un cambio de casilla de hace varias versiones
• Muchos editores modernos quieren convertirse en el lugar donde ocurre todo, pero Neovim se conforma con seguir siendo una parte afilada de un sistema más grande
• No intenta reemplazar al shell, sino trabajar junto con tmux, ripgrep, git, language servers, formatters, linters y test runners
• El hecho de que no necesite adueñarse de todo el escritorio también es una de las razones por las que Neovim ha durado tanto
• Desde 2011 aparecieron muchos editores, ecosistemas de extensiones, temas, marketplaces y paneles de IA, pero Vim ya era una herramienta vieja, y Neovim modernizó lo necesario sin abandonar lo que hacía que a la gente le importara

Modernización y recompensas de aprendizaje que duran

• Lua mejoró la configuración, y el ecosistema de plugins también mejoró mucho
• El LSP integrado lleva funciones de IDE al editor sin darle una sensación inflada
• Treesitter modernizó el resaltado de sintaxis y la comprensión del código, y Lazy.nvim hizo que la gestión de plugins fuera rápida y simple
• El atractivo central de Neovim es que lo que aprendes sigue siendo útil con el paso del tiempo
  • si aprendes un motion, te sigue ayudando
  • si escribes una macro, desaparece una edición tediosa
  • si descubres un objeto de texto, un refactor molesto se vuelve más fácil
  • si ajustas un comando, termina formando parte de tu mano
• Un editor no mejora porque una empresa lanzó una nueva barra lateral, sino porque el usuario se vuelve mejor usándolo
• La productividad es difícil de medir solo como “aquí me ahorré 5 segundos”; también está en reducir la fricción en miles de pequeñas ediciones
• Al moverte entre código, pruebas, git diff y resultados de búsqueda, puedes concentrarte en el problema sin sentir que te cambiaste a otra habitación
• Neovim, por su gran capacidad de programación, hace que formes tu propio flujo de trabajo en lugar de aceptar los valores por defecto
• Si algo incómodo se repite dos veces, por lo general puedes arreglarlo con un mapeo, un comando, una pequeña función en Lua, un mejor plugin o quitando un plugin
• La configuración evoluciona para adaptarse a tu forma real de trabajar, y cuando tienes claro el cambio que quieres, queda muy poco entre el pensamiento y la edición
• En 15 años cambiaron los lenguajes, los frameworks, el rendimiento de las máquinas y las modas de la industria, pero Vim y Neovim siguieron siendo el editor central donde ocurre el mejor trabajo

[GN⁺]

Opiniones de Lobste.rs

• Empecé a usar vim hace 12~14 años porque necesitaba un editor ligero que me mostrara el código justo enfrente.
  Empecé a aprender sin usar el mouse, y después me alegró descubrir que Mitchell Hashimoto también había aprendido vim de una forma parecida.
  Conocí neovim a través de TJ DeVries (https://www.youtube.com/@teej_dv) y su canal de YouTube, donde lo veía hackear neovim, telescope y varios proyectos más.
  El cambio a Lua se sintió natural, y me gustó porque ya era un lenguaje pequeño que me agradaba.
  Los primeros plugins que usé fueron treesitter y telescope, y hasta hoy sigo usando neovim junto con algunos plugins pequeños.
  neovim nunca se me ha roto; simplemente funciona bien. No uso plugins de LLM, y creo que ese ecosistema puede existir fuera del editor.
  Ojalá el equipo siga ofreciendo solo un editor de código ligero y enfocado.

  • Mi experiencia es parecida. Usé vim y emacs durante años, y aunque siempre preferí vim, siempre me dio envidia que elisp fuera un lenguaje de programación bastante decente, mientras que vimscript no tanto.
    Por eso me pareció muy atractivo que neovim añadiera Lua.

• Hace como 20 años, una vez pensé en qué cosas, aparte de la productividad, hacían que la vida diaria fuera más disfrutable.
  Al tope de la lista estaban linux y vim.
  Sin importar qué trabajo hiciera ni qué stack tecnológico usara, esos dos me garantizaban un entorno de trabajo ergonómico, familiar y cómodo.

• Empecé a aprender vim más allá de :wq cuando estaba en entrevistas en 2009. Todos en la empresa usaban vim, así que si quería trabajar con ellos, no había otra opción.
  Algunos incluso tenían desactivadas las teclas de dirección.
  Antes de eso, mi única experiencia con editores de terminal había sido usar pico en la universidad, y normalmente usaba los editores GUI de moda en esa época.
  Por suerte me contrataron, y desde entonces seguí usando vim.
  Últimamente me he dado cuenta de que la forma de pensar tipo vim se ha filtrado también a otras partes de mi vida en software.
  Creo que empezó cuando en macOS hice un teclado virtual en Hammerspoon para submapas de gestión de ventanas, y a finales del año pasado usar Arch Linux hizo que la gestión de ventanas en mosaico fuera facilísima.
  Hace ya un tiempo me cambié a neovim y me parece excelente.
  Sé que hay muchos chistes y discusiones sobre editores, pero salvo algunas excepciones, todavía me cuesta entender que la gente que escribe código profesionalmente no use vim, emacs o algo parecido.
  En cualquier profesión es importante elegir la mejor herramienta para el trabajo, y tratar la edición como un lenguaje es una gran ventaja en software.

  • El punto central del texto es “por qué amo Neovim”, no “por qué deberías usarlo”.
    Sobre esa parte de “me cuesta entenderlo”, el comportamiento, los atajos y los plugins de editores como VS Code también son muy útiles.
    Vale la pena leer bien la documentación de VS Code, porque realmente hace muchísimas cosas.
    Y para algunas personas, incluyéndome, mover el cursor con el mouse a cualquier lugar del búfer y seleccionar cualquier rango es simple y lo bastante rápido.
    KISS aplica aquí.
  • Uso el modo vi y los comandos de movimiento casi en todas partes, pero solo uso vi, vim, neovim o viper de emacs de vez en cuando.
    Muchas veces otros editores son mejores herramientas para ese trabajo.
    En Python, que es lo que más uso hoy en día, siento que PyCharm es una mejor herramienta que ellos.
    Por suerte existe IDEAVim, un plugin muy bueno, así que puedo mantener la memoria muscular.
    En Mac también ayuda que los atajos del sistema no choquen con los atajos de vi, así que puedes usar el que convenga según la situación.
    Cuando trabajo con C++, me parece que CLion es mejor herramienta, pero ahí también funciona IDEAVim.
    Para tareas varias de categoría ambigua suelo usar zed, y su emulación de vim también está bastante bien.
    Sin duda está bien tener un buen editor de terminal para conectarte a sistemas remotos, pero cuando puedes usar una GUI completa, no me gustan tanto los editores de terminal.
    Sí me gusta la edición modal, pero si no hace falta tirar a la basura la memoria muscular, creo que también hay buenas razones para usar un editor GUI.

• VS Code, tal como viene, ya es lo suficientemente bueno para muchísimos usos.
  Ya trae búsqueda de archivos con ctrl-p, ventanas divididas, resaltado de sintaxis y soporte para lenguajes populares.
  Como mínimo, quería que neovim trajera algo tipo ctrl-p por defecto, y que se convirtiera en una especie de Linux Mint de los editores tipo vim, con menos preocupaciones de seguridad y una barrera de configuración más baja.
  Entiendo totalmente eso de querer tener la misma sensación de editor de todos los días cuando haces programación en pareja en una sesión de tmux sobre SSH o arreglas algo en una ventanita de terminal.
  Me han pagado por escribir mucho código usando screen/vim sobre SSH, y antes de que existiera la interrupción constante de cosas como Slack sonando a cada rato, en verdad era muy productivo.
  Los depuradores visuales de Visual Studio o de IDEs de Jetbrains como CLion y Rider eran una de esas cosas para las que nunca encontré un reemplazo realmente bueno en ningún editor tipo vim.
  Tienen una potencia muy accesible, más que cosas como cgdb.
  La velocidad no es solo cuestión del tiempo de arranque, y neovim también va bien en eso, pero al cerrar, neovim por defecto es notablemente más lento que vim.
  No tarda muchísimo, pero en mi entorno sí se lleva como 1 segundo.

• Me gusta el modelo de vim. La edición modal es solo una parte pequeña; lo que valoro más de vim frente a helix o a un IDE común es que puedes aprenderlo de forma gradual.
  Primero entiendes los keybindings y cómo configurar opciones; luego, si algo no funciona en Windows, metes condiciones en la configuración; después escribes autocmd y funciones, y con lo que ya aprendiste hasta terminas extendiéndolo con plugins pequeños.
  Aun así, no diría que amo de verdad vim o neovim.
  vim lleva décadas con los mismos bugs raros sin corregir, y neovim ha arreglado muchos bugs, pero también ha metido otros nuevos.
  El mayor pecado de neovim es romper la API de Lua en cada actualización.
  Ya me cansé de ver avisos de deprecación cada vez que lo ejecuto y de tener que arreglar la configuración antes de hacer lo que quería hacer.
  Si al menos algunas funciones nuevas no fueran exclusivas de Lua, sería menos grave.
  Si no, podría haber seguido usando solo vimscript y estar tranquilo con una compatibilidad que se ha mantenido por más de 20 años.