El flujo definitivo y mantener el nivel · Neovim

Has construido las piezas. Esta lección las une: cómo se siente un día real de desarrollo con todo funcionando, cómo mantener el setup sano y afilado, y qué mentalidad separa a quien “usa Neovim” de quien lo ha convertido en una extensión de su mente.

🎯 Al terminar esta lección sabrás

Ver el flujo completo integrado en un día de trabajo.
Mantener la config sana: checkhealth, colisiones de teclas, rendimiento, actualizaciones.
Convivir con los dos gestores de plugins sin duplicar trabajo.
Hábitos para seguir mejorando sin romper nada.

Un día de nivel dios

flowchart LR
S[Terminal - z proyecto] --> Z[Multiplexor - sesion y layout]
Z --> N[nvim con leader ff]
N --> E[Editar - gramatica Vim y Treesitter]
E --> L[LSP - navegar, documentar, code action]
L --> C[Completado - nativo o blink]
C --> AI[IA - sugerencia inline y refactor revisado]
AI --> G[lazygit - commit]
G --> D[nvim-dap - depurar si falla]
D --> E
style S fill:#a6e3a1,color:#11111b
style N fill:#89b4fa,color:#11111b
style AI fill:#cba6f7,color:#11111b
style G fill:#fab387,color:#11111b

Un flujo real, sin tocar el ratón:

Abres el terminal, z api te lleva al proyecto. Tu sesión de zellij/tmux revive con el editor, el servidor y los logs donde los dejaste.
<leader>ff para abrir el archivo, o <leader>fg para buscar esa función a medias recordada.
Editas con la gramática de Vim y objetos de Treesitter: cif, daf, s para saltar, <leader>rn para renombrar seguro.
El LSP te guía con atajos que no configuraste: Ctrl-] navega, K documenta, gra arregla, grn renombra. El menú de completado sale solo —nativo o con blink.cmp, según lo que montaras en la lección 2.2— y la sugerencia inline propone lo obvio.
Un refactor mayor: seleccionas, <leader>ai, revisas el diff, aceptas.
<leader>gg (lazygit) para el commit. Si algo falla, <leader>db + <leader>dc para depurarlo en vivo.
Navegas al panel de logs con Ctrl-j sin pensar si es Neovim o el multiplexor.

Todo encadenado, a velocidad de pensamiento.

Mantener los plugins al día

El reparto entre gestores lo decidiste en la lección 1.2. Lo único que hace falta recordar aquí es que cada uno tiene su ciclo de mantenimiento, y son distintos:

	lazy.nvim	vim.pack
Actualizar	`:Lazy sync`	`vim.pack.update()`
Ver qué hay instalado	`:Lazy`	`vim.pack.get()`
Borrar	`:Lazy clean`	`vim.pack.del({ "nombre" })`
Lockfile	`lazy-lock.json`	`nvim-pack-lock.json`
Medir el arranque	`:Lazy profile`	`nvim --startuptime arranque.log`

Los dos lockfiles van a Git: son la foto exacta de tu setup, y en otra máquina los plugins que falten se instalan solos a la revisión correcta. No los edites a mano.

Mantén la config sana

🩺

:checkhealth

Ejecútalo tras cambios grandes o actualizaciones. Detecta dependencias rotas, providers y problemas de LSP. Acepta argumentos para acotar: :checkhealth lsp.

⌨️

:verbose map

El diagnóstico que casi nadie usa y que resuelve los fallos más desconcertantes. Te dice quién tiene una tecla y en qué archivo se la quedó.

⏱️

Medir el arranque

:Lazy profile para lo que gestiona lazy, y nvim --startuptime para el total real. Si algo lo dispara, revisa su carga.

🔒

Lockfiles en Git

lazy-lock.json y nvim-pack-lock.json. Con ellos tu config es reproducible en cualquier máquina; sin ellos es una lotería.

💡

Versiona tu config en Git

Tu ~/.config/nvim es tu obra. Ponlo en un repositorio: así experimentas sin miedo (siempre puedes volver atrás), lo replicas en cualquier ordenador, y llevas tu entorno contigo. Incluye los dos lockfiles.

El fallo que no da error: colisiones de teclas

Casi todos los “este plugin está roto” que vas a vivir no son bugs: son dos plugins que quieren la misma tecla. Y es el peor tipo de fallo, porque no produce ningún error. La función simplemente deja de responder, gana el que cargó último, y a veces cambia entre arranques.

Los reincidentes, por si acaso:

<C-Space> y <Tab> pertenecen al completado. Si un plugin de saltos o de IA se los queda, tu autocompletado enmudece sin dar ningún error (lecciones 2.2 y 3.4). Ojo: la selección incremental de Treesitter ya no entra en este reparto, porque en 0.12 es nativa y vive en an, in, ]n y [n. Solo choca si vienes de una config vieja o de una distro.
s y S los tiene flash.nvim como moción, y mini.surround vive en el prefijo gs. Los dos no pueden ocupar s: si aceptas los valores por defecto de ambos, uno desaparece según el orden de carga (lección 2.3).
gr a secas tapa la familia entera de LSP que Neovim crea sola: grn, gra, grr, gri, grt y grx. Antes de mapear cualquier cosa que empiece por g, mira qué hay debajo (lección 2.1).

El diagnóstico son tres comandos y quince segundos:

:map <C-Space>
:imap <Tab>
:verbose map gr

:map cubre Normal, Visual y operador; :imap es la que importa para todo lo que vive en Insert; y :verbose añade el archivo y la línea exactos donde se definió el mapeo ganador. Conviértelo en un reflejo: cada vez que instales un plugin que hable de “saltar”, “seleccionar”, “aceptar” o “sugerir”, pregúntale al editor qué teclas se ha llevado.

Rendimiento

Si Neovim se siente lento:

:Lazy profile para ver qué plugin gestionado por lazy cuesta al arrancar y afinar su carga perezosa.
nvim --startuptime arranque.log para el arranque completo, incluido lo que carga vim.pack y lo que hace tu propio init.lua.
:checkhealth para detectar un LSP mal configurado que reindexa de más.
En archivos gigantes, Treesitter y algunos plugins pueden pesar; existen plugins como bigfile (en snacks) que los desactivan automáticamente.

La mentalidad para no estancarse

⚡

Nunca terminas, y esa es la gracia

Neovim no es un producto acabado: es un jardín que cultivas. La diferencia entre un usuario avanzado y uno de nivel dios no es saberlo todo — es el hábito de mejorar una cosa cada semana. ¿Repetiste un movimiento incómodo tres veces? Búscate un objeto de texto o un atajo mejor. ¿Un plugin nuevo resuelve algo que hacías a mano? Pruébalo un día. Pequeñas mejoras compuestas durante meses te llevan a un dominio que ningún IDE cerrado puede darte, porque es tuyo.

Y el movimiento contrario cuenta igual: cada versión de Neovim absorbe cosas que antes eran plugins. El completado, el gestor de plugins, el completado inline de la IA, los comentarios con gc. Una config de nivel dios no es la que más plugins tiene, es la que quita los que ya sobran.

Para seguir creciendo:

:help es la mejor documentación de cualquier editor. :help ciw, :help :g, :help lsp. Vive ahí.
:help news tras cada actualización: lista lo que cambió, lo que se ha vuelto nativo y lo que se ha marcado como obsoleto. Es la lectura que te ahorra reinstalar plugins que ya no necesitas.
Lee configs ajenas (LazyVim, kickstart.nvim, dotfiles en GitHub) y roba ideas.
La comunidad: r/neovim, awesome-neovim para descubrir plugins, y dotfyle.com para ver qué usan otros.

Lo lograste

Empezaste sin saber salir del editor. Ahora dominas la gramática modal, construiste tu propia config en Lua, montaste un IDE para C, Rust, Swift y frontend, orquestas la terminal con multiplexores, automatizas lo repetitivo e integras IA con criterio. Eso es nivel dios.

Ten a mano el Cheatsheet para consultar y la Config completa como plantilla. Y recuerda: la única forma de mantener el nivel es usarlo cada día.

⚔️ Tu ritual de mantenimiento

Convierte tu ~/.config/nvim en un repo Git, con lazy-lock.json y nvim-pack-lock.json dentro.
Ejecuta :checkhealth y resuelve cualquier aviso pendiente.
Actualiza por los dos caminos: :Lazy sync y vim.pack.update(). Lee el búfer de confirmación de este último antes de escribir.
Ejecuta :map <C-Space>, :imap <Tab> y :verbose map gr. Resuelve las colisiones que encuentres.
Mira tu :Lazy profile y tu nvim --startuptime y anota el plugin más caro.
Elige una cosa que hagas de forma incómoda y busca en :help una manera mejor.
Vuelve aquí dentro de un mes y repite los pasos 4 y 6. Ese es el bucle infinito del nivel dios.