Cierre: el mapa de lo aprendido y el editor que ahora es tuyo

Este es el último capítulo, y su trabajo no es enseñarte nada nuevo sino colocar en una sola imagen lo que llevas veintiséis niveles construyendo por partes. Empezaste aprendiendo a moverte sin flechas y terminas sabiendo cómo se genera la API del editor desde sus firmas en C; entre esos dos extremos hay una progresión que probablemente no viviste como progresión, porque cada nivel parecía un tema y no un peldaño. Vista entera, la escalera tiene una forma muy clara y va de usar una herramienta a fabricar herramientas con ella, y de ahí a modificar la herramienta misma. Lo que sigue es el mapa, la dirección en la que se mueve el terreno y la única pregunta que queda por contestar, que ya no es técnica.

El mapa de los veintiséis niveles

El recorrido tiene cuatro tramos y cada uno es un cambio de posición respecto al editor.

En el primero usas. Aprendes que la edición modal no es un teclado incómodo sino una gramática: verbos que son operadores, complementos que son movimientos y objetos de texto, cuantificadores que son contadores. Los registros, las marcas, las macros, la lista de saltos y el quickfix dejan de ser funciones sueltas y se revelan como el vocabulario de un lenguaje que se compone. El logro de este tramo no es velocidad, es que la distancia entre pensar una edición y ejecutarla se acorta hasta desaparecer.

Ese primer tramo tiene además una propiedad que ninguno de los siguientes comparte: es el único que se paga entero por adelantado. Durante unas semanas escribes más despacio que antes, y esa curva descendente es la razón por la que la mayoría de la gente abandona la edición modal antes de que empiece a rendir.

En el segundo configuras. Lua entra en escena, y con él la idea de que el editor se describe en un lenguaje de programación real, con módulos, tablas y funciones. Descubres la API y su introspección, los autocomandos como sistema de eventos, los mapeos como diseño de vocabulario propio, las opciones y sus ámbitos. El cambio de posición aquí es sutil pero decisivo: dejas de buscar el ajuste que otro configuró y empiezas a expresar lo que quieres.

En el tercero extiendes. Marcas extendidas, resaltados, Treesitter con sus queries, el protocolo de servidores de lenguaje y su cliente, el primer plugin, su API pública, su documentación, sus pruebas, su interfaz y su rendimiento. Aquí ya no configuras un editor: escribes software que otras personas ejecutan dentro del suyo, con todo lo que eso implica de contrato, compatibilidad y responsabilidad.

Y en el cuarto entiendes y transformas. La plataforma completa en siete capas, el protocolo que separa el editor de su pantalla, el código fuente como documentación definitiva y el proceso por el que ese código cambia. El editor deja de ser un objeto dado para convertirse en un artefacto histórico, hecho por gente con criterios discutibles, al que puedes añadir tu propio criterio.

Hay una prueba sencilla para saber si un tramo está realmente consolidado, y no es la de recordar comandos. En el primero, la señal es que ya no piensas en teclas sino en operaciones, y que ver a alguien editar con el ratón te resulta físicamente lento. En el segundo, la señal es que ante un comportamiento que no te gusta tu primera reacción es abrir tu configuración, no un buscador. En el tercero, es que has escrito algo que otra persona usa y has tenido que decidir qué no ibas a añadirle. Y en el cuarto, la señal es que cuando el editor hace algo inexplicable, se te ocurre ir a mirar por qué. Si alguno de esos cuatro reflejos todavía no está, ahí está tu trabajo pendiente, y ninguno de ellos se adquiere leyendo.

flowchart LR
A[Usar: la gramatica de la edicion] --> B[Configurar: Lua, API, eventos]
B --> C[Extender: extmarks, treesitter, LSP, plugins]
C --> D[Transformar: protocolo, codigo fuente, contribuir]
A -.-> A1[Deja de haber friccion entre pensar y editar]
B -.-> B1[Deja de hacer falta que otro lo haya resuelto]
C -.-> C1[Empiezas a producir para otros]
D -.-> D1[El editor deja de ser una caja cerrada]
style D fill:#cba6f7,color:#11111b
style D1 fill:#a6e3a1,color:#11111b

Conviene decir también algo sobre los tramos que no se recorren enteros, porque nadie los recorre enteros. Es perfectamente razonable haber pasado de largo sobre las marcas extendidas o sobre las pruebas de plugins si tu trabajo no las pedía. Lo que no es razonable es haberse saltado un tramo completo, porque cada uno es el suelo del siguiente: quien intenta escribir un plugin sin haber interiorizado el sistema de eventos produce código que funciona por accidente, y quien lee el núcleo sin haber escrito un plugin no tiene con qué comparar lo que lee. Si al revisar el mapa detectas un tramo entero en sombra, vuelve a él antes que a cualquier cosa nueva: el rendimiento de rellenar un hueco de base es siempre mayor que el de añadir una técnica más arriba.

Hacia dónde va el editor

Cualquier predicción concreta envejece mal, pero las direcciones de fondo llevan años siendo estables y conviene tenerlas presentes porque condicionan lo que merece la pena escribir.

La primera es la absorción en Lua de lo que antes era plugin. El cliente de servidores de lenguaje, el analizador incremental, los diagnósticos, el autocompletado básico y la gestión de plugins han ido entrando en el runtime distribuido, siempre con el mismo patrón: primero existen como plugin de terceros, se decanta una forma buena, y lo que queda es una primitiva compartida que el núcleo puede sostener. La consecuencia para ti es doble: revisa periódicamente si algo de tu configuración ya viene de fábrica, y asume que un plugin muy popular es un candidato a desaparecer por integración, que es la mejor forma de morir que tiene un plugin.

La segunda es la retirada progresiva de Vimscript del runtime, no del editor. El intérprete se queda por compatibilidad, pero el código nuevo se escribe en Lua y el que ya existe se traduce. Escribir Vimscript hoy en algo que vaya a durar es una decisión difícil de defender, aunque saber leerlo seguirá siendo útil durante años, porque una parte enorme del ecosistema histórico está escrita en él y porque la documentación heredada lo usa en sus ejemplos.

De esa primera tendencia se sigue un consejo concreto sobre cómo escribir a partir de ahora: apóyate en las primitivas del runtime antes que en abstracciones de terceros. Un plugin que use directamente los diagnósticos, las marcas extendidas y el cliente de servidores de lenguaje distribuidos sobrevivirá a los cambios de moda; uno construido sobre la capa de conveniencia de otro plugin heredará su ciclo de vida. No es una regla contra el ecosistema, es una regla sobre dónde poner los cimientos.

La tercera es la maduración del protocolo de interfaz. Cuantos más widgets se delegan a los clientes mediante extensiones, más se parece el núcleo a un motor de edición puro y más margen tienen las interfaces para diferenciarse. Ahí está el espacio donde seguirán apareciendo cosas que hoy no imaginamos, incluidas las que incrusten el editor dentro de otras aplicaciones.

Y la cuarta es la presión constante sobre la latencia. El parseo asíncrono, el trabajo por rangos y la vigilancia sobre el arranque responden todos al mismo objetivo, que es que ninguna capacidad nueva se pague con retardo perceptible. Es también el criterio con el que se juzgará lo que tú escribas.

Hay una quinta tendencia que no es del proyecto sino del entorno, y que conviene mirar de frente: la irrupción de los asistentes de programación ha cambiado dónde está el valor de saber usar un editor. Escribir texto rápido importa menos que antes; saber exactamente qué quieres que ocurra y poder expresarlo sin fricción importa más. Un editor cuyo estado completo es consultable y cuyas operaciones son todas invocables desde un lenguaje resulta ser, casualmente, la clase de entorno que mejor se compone con herramientas que generan y transforman código, porque todo lo que necesita coordinarse tiene una llamada. La conclusión práctica no es que este conocimiento se devalúe, sino que se desplaza: menos pulsaciones por minuto, más diseño de flujos y más criterio sobre qué automatizar.

Qué construir ahora

La respuesta habitual —haz un plugin— es demasiado vaga para ser útil. Hay cuatro clases de proyecto y se distinguen por a quién sirven y cuánto cuesta mantenerlos.

Antes de elegir, conviene aplicar el mismo criterio que gobierna las decisiones del núcleo, ahora a escala de tu tiempo: lo caro nunca es escribir algo, sino mantenerlo. Una herramienta interna que solo usas tú puede romperse sin consecuencias y morir el día que deje de servir. Un plugin público con usuarios te ata a una API que ya no puedes cambiar y a una cola de incidencias que no elegiste. No hay respuesta correcta entre ambas, pero sí hay una respuesta deshonesta, que es publicar sin haber decidido si vas a sostenerlo.

La primera es la herramienta interna de tu proyecto: aquella regla que tu equipo repite en cada revisión de código y que es una query de diez líneas sobre el árbol, o el comando que automatiza el ritual de crear un módulo con su prueba y su registro. No sirve a nadie más, no necesita documentación pública ni versiones, y es con enorme diferencia la que más valor produce por hora invertida.

Para la primera clase existe además un atajo que casi nadie aprovecha: tu configuración ya contiene el inventario. Los mapeos que has definido, los autocomandos que has colgado y los comandos que has creado son el registro literal de las operaciones que tu trabajo repite, y basta con listarlos para ver dónde se concentra la fricción real frente a la imaginada.

-- El inventario de lo que de verdad automatizas, ordenado por densidad
local mapas = vim.api.nvim_get_keymap("n")
print(("mapeos normales definidos: %d"):format(#mapas))

for _, grupo in ipairs(vim.api.nvim_get_autocmds({})) do
  if grupo.group_name and not grupo.group_name:match("^nvim") then
    print(grupo.group_name, grupo.event, grupo.pattern)
  end
end

print(vim.inspect(vim.tbl_keys(vim.api.nvim_get_commands({ builtin = false }))))

La segunda es el plugin público, que solo tiene sentido si resuelve algo que aún no está resuelto y si estás dispuesto a la parte que no es escribir código: responder incidencias, no romper a tus usuarios, decidir qué no vas a añadir. Publicar es un compromiso, no un acto de generosidad puntual.

La tercera es la contribución al proyecto, ya sea documentación, pruebas o núcleo. Su rendimiento no está en el cambio sino en lo que aprendes sometiendo tu criterio a alguien que conoce el sistema mejor que tú, que es una experiencia sorprendentemente escasa en una carrera profesional normal.

Y la cuarta, la menos evidente y quizá la más valiosa: enseñar. Escribir lo que has entendido, explicárselo a alguien de tu equipo, defender por qué una cosa pertenece al núcleo y otra no. Es la única actividad que revela con precisión los huecos de tu modelo, porque una explicación con un agujero se derrumba delante de testigos.

Sea cual sea la que elijas, hay un fallo de modo que conviene nombrar porque acecha justo en este punto del recorrido: confundir configurar el editor con trabajar. Cuando uno adquiere la capacidad de modificarlo todo, ajustar la herramienta se vuelve una actividad agradable, con resultados inmediatos y sin las incertidumbres del trabajo de verdad. Es una trampa reconocible: si al final de la semana has mejorado tu configuración y no has terminado nada más, la plataforma te está usando a ti. La medida correcta del éxito de todo este recorrido no es lo sofisticada que sea tu instalación, sino cuántas veces al día dejas de pensar en ella.

-- El unico habito que sostiene todo lo demas: medir lo que crees saber
vim.api.nvim_create_user_command("Medir", function(o)
  local t0 = vim.uv.hrtime()
  vim.cmd(o.args)
  vim.notify(("%s: %.2f ms"):format(o.args, (vim.uv.hrtime() - t0) / 1e6))
end, { nargs = "+", complete = "command" })

-- Y la disciplina que evita que la configuracion se pudra:
--   :checkhealth        una vez al mes
--   :h news             en cada version
--   startuptime         antes y despues de cada plugin nuevo

Esa última idea, la de medir, es el hilo que atraviesa los veintiséis niveles y el único hábito que conviene sacar de aquí sin negociación. Medir el arranque antes de culpar a un plugin. Medir el reparseo antes de desactivar el analizador. Medir la latencia de un autocomando antes de reescribirlo. Cronometrar una llamada por canal antes de decidir en qué lenguaje escribir algo. En todos esos casos la intuición falla con una regularidad que sorprende, y el coste de comprobarla es de segundos. Un ingeniero que mide toma decisiones que sobreviven a la revisión de otros; uno que opina las defiende con anécdotas.