¿Distribución o config desde cero?

Llevas cuatro niveles construyendo un editor a tu medida: tu init.lua, tus specs, tu LSP, tu entorno. Y ahora esta guía te va a enseñar, con el mismo cuidado, la alternativa que llevas cuatro niveles no usando: instalar una configuración completa hecha por otros. No es una contradicción, es el orden correcto. La pregunta «¿distro o desde cero?» solo se puede responder con criterio después de haber construido, porque antes no sabes qué te están vendiendo ni qué te están cobrando. Este nivel existe para que esa decisión sea tuya y no del primer vídeo que te la venda.

• Definir qué es una distribución de Neovim y qué problema resuelve exactamente.
• Medir qué parte de ese problema se la ha comido el propio editor en 0.12.
• Poner nombre a los tres ejes de la decisión: tiempo, control y deuda de conocimiento.
• Situar kickstart.nvim como lo que es: ni distro ni config, sino un punto de partida que se lee.
• Probar una distro completa con NVIM_APPNAME sin tocar ni tu config ni tus datos.
• Salir de la lección con una decisión tomada por ti, no comprada.

Qué es una distribución

Una distribución es una configuración completa y mantenida por la comunidad, lista para usar: gestor de plugins, LSP, completado, Treesitter, Git, formateo, buscador, statusline y un mapa de teclas ya diseñado, todo pre-cableado y funcionando desde el primer arranque. Tú la instalas y, si quieres, la personalizas encima.

Una distro no es otro editor

Sigue siendo Neovim con plugins y Lua — exactamente lo que ya sabes montar. La diferencia es que alguien ya ensambló las piezas por ti y las mantiene. Todo lo que aprendiste (specs de lazy.nvim, opts, LSP nativo, vim.pack, lockfiles) sigue aplicando; de hecho es lo que te permitirá leerla por dentro en las próximas lecciones.

Pero hay una diferencia estructural que conviene ver desde el principio, porque es la que de verdad separa los dos caminos. En tu config del Nivel 2 tú llamas a las piezas: eliges un plugin, escribes su spec, decides cuándo carga y qué teclas ocupa. En una distro la relación se invierte: la base decide y tú declaras excepciones. La distro trae cuarenta decisiones tomadas — qué picker, qué motor de completado, qué tecla hace qué — y tu trabajo pasa de construir a corregir lo que no te encaje. Ninguna de las dos relaciones es mejor; son distintas, y cada una cobra un precio distinto. Volveremos a esto al final, porque es un patrón mucho más grande que Neovim.

Qué cambió con 0.12

Durante años el argumento a favor de las distros fue sólido y sencillo: montar un IDE a mano exigía media docena de plugins delicados y bien coordinados entre sí, y el que no quería pagar ese peaje instalaba una distro. Ese coste ha bajado mucho, y hay que actualizar la cuenta.

Traducido: hoy puedes tener un entorno de trabajo decente con muy pocos plugins, y el init.lua que lo sostiene cabe en una tarde — lo sabes de primera mano porque es lo que hiciste en los Niveles 2 y 3. Eso debilita el argumento de «una distro te ahorra el infierno del cableado», porque buena parte de ese cableado ya no existe.

Lo que 0.12 NO te regala

Sé honesto con la otra mitad de la cuenta. El editor no instala por ti los binarios de los servidores (los pones tú o los pone Mason), no trae buscador difuso de archivos, ni indicadores de Git en el margen, ni formateo al guardar, ni depurador, ni un statusline decente, ni —sobre todo— un vocabulario de atajos ya diseñado y coherente, con which-key describiéndolo entero. Eso último es la mitad del valor de una distro y casi nunca se menciona: no es software, es diseño, y el diseño no viene en el core de ningún editor.

Los tres ejes: tiempo, control, deuda de conocimiento

Casi todas las discusiones de «distro sí o no» son diálogos de sordos porque cada bando está optimizando un eje distinto sin decirlo. Ponles nombre y la discusión se vuelve aburrida, que es lo que debe ser.

Tiempo. Una distro te da hoy, en veinte minutos, lo que a ti te costó dos niveles de esta guía. Y —esto es lo que más pesa a largo plazo— te sigue ahorrando tiempo después: cuando un plugin central se reescribe de forma incompatible, el mantenedor de la distro adapta la configuración y tú solo actualizas. Le pasó a todo el ecosistema cuando nvim-treesitter migró a su rama main reescrita: los usuarios de LazyVim absorbieron el cambio en una actualización; los de config propia tuvieron que leer, entender y reescribir. Tú lo hiciste en el Nivel 2, y sabes lo que costó.

Control. En tu config, cada comportamiento del editor tiene una línea que lo causa y tú sabes cuál. En una distro, el comportamiento por defecto viene de un código que no escribiste, y cambiarlo requiere primero descubrir dónde vive y luego aprender el mecanismo de override (lección 5.3). El control no se pierde — LazyVim está diseñada para devolvértelo — pero deja de ser gratis: cada desviación de la base es un pequeño proyecto de arqueología.

Deuda de conocimiento. Este es el eje que los otros dos esconden. Si usas una distro sin haber construido nunca, acumulas una deuda invisible: el editor funciona, pero no sabes por qué funciona, y el día que algo se rompa no sabrás ni en qué archivo mirar. Esa deuda no se nota mientras todo va bien, que es exactamente lo que la hace peligrosa — como toda deuda, se cobra con intereses y en el peor momento. Tu posición aquí es privilegiada y conviene decirlo sin falsa modestia: tú ya pagaste ese conocimiento por adelantado en los Niveles 1 a 4. Para ti, adoptar una distro no genera deuda; es una decisión de conveniencia entre iguales.

La deuda de conocimiento no impide usar el editor: impide repararlo. Y un editor que no sabes reparar es un editor que te puede dejar tirado.

Qué te da una distro que tu config no

Con los tres ejes sobre la mesa, la lista concreta. Esto es lo que una distro madura pone encima de tu config de los Niveles 2–3:

• Curación. Elegir cuarenta plugins que no se pisen entre sí — ni en teclas, ni en eventos, ni en responsabilidades — es trabajo real y continuo. En una distro ya está hecho, y rehecho cada vez que el ecosistema cambia.
• Un idioma de teclas. Grupos coherentes bajo <leader>, descripciones en which-key, la misma lógica en todos los plugins. Diseñar eso lleva años de iteración; heredarlo, un minuto.
• Integraciones por lenguaje empaquetadas. LSP, formateador, depurador y parser de un lenguaje, coordinados y probados juntos (los Extras de LazyVim, lección 5.4).
• Mantenimiento absorbido. Los cambios de ruptura del ecosistema los amortigua el mantenedor, no tú.
• Estadística. Miles de personas con tu misma configuración exacta significa que tu bug ya tiene issue, tu pregunta ya tiene respuesta y tu caso raro ya no es raro.

Qué te quita

La misma honestidad en la otra columna:

• El reparto del teclado. Heredas decisiones sobre teclas que quizá ya usabas para otra cosa — LazyVim, por ejemplo, cede s, S y <C-Space> a flash.nvim, y esa última es justo la que este curso reserva para el completado. Recuperarlas se puede (lección 5.3), pero es trabajo tuyo.
• La pila heredada. La distro monta su propia capa — su gestor de LSP, su motor de completado, sus utilidades — por encima de lo que 0.12 ya sabe hacer solo. No es un defecto, es compatibilidad y features; pero son capas que existen entre tú y el editor.
• El churn ajeno. Las distros también cambian de opinión: LazyVim ha cambiado de buscador por defecto más de una vez en su historia. Cada actualización mayor puede mover algo que ya tenías en la memoria muscular, y esa decisión no la tomaste tú.
• La superficie de depuración. Cuando algo falla, la pregunta ya no es «¿qué escribí mal?» sino «¿en qué capa de las cuatro está el fallo?». Con tu mapa mental del Nivel 3 es asumible; sin él, es niebla.

El panorama en 2026

kickstart.nvim

No es una distro: es una config mínima de un archivo, comentada línea a línea para aprender. Punto de partida para construir la tuya, no destino.

LazyVim

La más popular, de folke (autor de lazy.nvim, which-key y flash). Modular, con un sistema de Extras y documentación excelente. La que usamos en este nivel.

NvChad

Muy rápida y cuidada estéticamente, con un framework de UI propio. Si te importa el aspecto y el arranque, mírala.

AstroNvim

Completa y muy configurable, con su propio ecosistema de plugins de comunidad.

kickstart: la tercera vía

kickstart.nvim merece un párrafo aparte porque resuelve un problema distinto y la gente lo mete en el saco equivocado. No es una distribución: su propio propósito declarado es ser un punto de partida, no un producto. Es un solo archivo, con menos plugins que dedos, donde cada bloque lleva un comentario que explica qué hace y por qué — está pensado para que lo leas entero antes de arrancarlo, cosa imposible con las decenas de miles de líneas de una distro.

Para ti, a estas alturas, kickstart tiene un uso concreto: es una segunda opinión. Tú ya construiste tu config; leer cómo kickstart resuelve los mismos problemas —qué plugins consideró imprescindibles, cómo comenta sus decisiones— es una revisión de código de tu propio trabajo. Si esta guía no existiera, kickstart sería la forma correcta de empezar: se lee en una hora y al terminar la config es tuya, porque la entiendes. Esa es la diferencia con una distro, y es toda la diferencia: kickstart transfiere conocimiento; una distro transfiere resultado.

Comprueba la fecha antes de copiar

El cambio de 0.12 dejó obsoleta una cantidad enorme de material: configuraciones de Treesitter con la API de la rama muerta, montajes de LSP a través de capas que ya no hacen falta, discusiones de gestores que asumen que hay que elegir uno. Antes de copiar una config ajena —de una distro, de un blog o de un dotfiles famoso— mira cuándo se escribió y contra qué versión. Es el mismo reflejo que ya tienes con las respuestas de los foros.

Pruébala sin casarte: NVIM_APPNAME

Aquí está la herramienta que convierte esta lección de teórica en práctica, y ya la conoces de la lección 0.2: NVIM_APPNAME cambia el nombre de carpeta que Neovim usa para todo — config (~/.config/<nombre>), datos (~/.local/share/<nombre>), estado y caché. Dos valores distintos de la variable son dos instalaciones completamente aisladas: ni comparten plugins, ni lockfile, ni historial, ni se pueden romper entre sí.

Eso significa que puedes tener LazyVim entera, funcionando, sin mover ni un archivo de tu config:

# tu config de siempre sigue intacta en ~/.config/nvim# 1) clona el starter de LazyVim en OTRA carpeta de configgit clone https://github.com/LazyVim/starter ~/.config/nvim-lazyrm -rf ~/.config/nvim-lazy/.git# 2) arranca Neovim apuntando a esa carpetaNVIM_APPNAME=nvim-lazy nvim# 3) ¿quieres que sea cómodo mientras dura el experimento?alias lvim='NVIM_APPNAME=nvim-lazy nvim'

El primer arranque instala sus plugins en ~/.local/share/nvim-lazy, sin rozar los tuyos. Puedes alternar entre tu editor y el experimento durante semanas, compararlos con los mismos proyectos reales, y el día que decidas, borrar dos carpetas o adoptar la nueva. Ningún paso de esta decisión requiere ya fe: todo se puede medir en tu máquina, con tu código.

Dos carpetas de config, dos de datos, cero interferencia. La lección 5.2 asume que ya lo hiciste.

Gestor, completado, LSP, Treesitter y comentarios ya vienen de fábrica. La lista de lo que queda es tu dependencia real.

Anota cada decisión que kickstart toma distinta a la tuya y pregúntate por qué. Es la revisión de código más barata que existe.

El balance, sin vender nada

No hay una respuesta buena. Hay una respuesta tuya, y depende de qué estés optimizando:

Los dos caminos tienen un fallo típico, y conviene nombrarlos los dos. El de la distro es usarla sin entenderla: la deuda de conocimiento de la que hablamos arriba, cobrándose. El de la config a mano es el mantenimiento infinito: pasar más tiempo afinando el editor que escribiendo código, y llegar a una configuración de cuarenta plugins que nadie mantiene salvo tú — es decir, convertirte en el mantenedor único de una distro con un solo usuario.

Por qué LazyVim en este nivel

Por dos razones prácticas, no por devoción. La primera: está construida sobre lazy.nvim, que ya conoces de la lección 2.2, y su estructura es la misma que montaste tú (lua/config, lua/plugins), así que no tienes que aprender un modelo nuevo — solo ver cómo lo usa otro a gran escala. La segunda: su sistema de Extras te da soporte de lenguajes con una línea, que es el mejor ejemplo posible de lo que una distro aporta de verdad.

Y hay una tercera razón, transferible: aprender a manejarla te enseña a leer y extender configuraciones ajenas. Esa habilidad la usarás cada vez que heredes el setup de otra persona, contribuyas a un proyecto con convenciones propias o busques cómo resolvió alguien un problema que tú tienes. Las próximas cuatro lecciones son, en el fondo, un curso de eso.

Librerías y frameworks: quién llama a quién

La decisión de esta lección tiene un nombre técnico fuera de Neovim, y reconocerlo te servirá el resto de tu carrera: es la diferencia entre una librería y un framework, y el criterio para distinguirlos es una sola pregunta — ¿quién llama a quién?

A una librería la llamas tú: eliges las piezas, decides el orden, escribes el pegamento, y el programa resultante es tuyo con partes ajenas. Un framework te llama a ti: él trae la estructura, el flujo y las decisiones, y tú rellenas los huecos que te deja — tu código son excepciones a su norma. Tu config del Nivel 2 es Neovim usado como librería: lazy.nvim, vim.lsp, cada plugin, son piezas que tú orquestas. LazyVim es Neovim convertido en framework: la orquesta ya suena y tú diriges solo los compases que declares.

Lo que hace útil esta distinción es que predice los costes antes de pagarlos, en cualquier tecnología. Un framework te da velocidad inicial y decisiones amortizadas entre miles de usuarios, a cambio de que salirte del camino previsto cueste más que no haber tenido camino — todo el que ha peleado contra las convenciones de Rails o de un framework de UI conoce esa fricción exacta. Una librería te da control total y cero magia, a cambio de que todas las decisiones, incluidas las aburridas, sean trabajo tuyo — y de que tu ensamblaje solo lo mantengas tú. Por eso la pregunta «¿framework o librerías?» no tiene respuesta universal y sí una advertencia universal: el framework sale rentable exactamente mientras tu caso se parezca al caso para el que fue diseñado, y las dos lecciones que vienen van justo de qué hacer cuando deja de parecerse.

Y hay una asimetría final que es la moraleja del nivel entero: quien solo sabe usar el framework no puede salir de él; quien sabe usar las librerías puede entrar y salir cuando quiera. Tú construiste primero. Esa es tu posición de fuerza, aquí y en todo lo demás.

Decide con criterio

1. Escribe la lista de plugins de los que dependes hoy y marca los que 0.12 ya cubre de fábrica. Suele sorprender.
2. Instala LazyVim bajo NVIM_APPNAME=nvim-lazy siguiendo los pasos de esta lección, y comprueba que tu config de siempre sigue intacta: nvim abre la tuya, NVIM_APPNAME=nvim-lazy nvim abre la distro.
3. Abre el mismo proyecto real con las dos y trabaja diez minutos en cada una. Anota qué te dio la distro que no tenías y qué te faltó de lo tuyo.
4. Lee kickstart.nvim de arriba abajo (es un archivo) y apunta dos decisiones suyas que adoptarías en tu config.
5. Responde para ti, por escrito, qué estás optimizando ahora mismo: ¿comprensión, tiempo o mantenimiento? La respuesta decide tu camino, y nadie más puede dártela.
6. Si eliges distro, comprométete a una regla: no instalar nada cuyo archivo no sepas localizar. Las siguientes lecciones te dan las herramientas para cumplirla.