Luna, Luna, Luna
================
23 de enero, 2023

Ha pasado algo así como un año y medio desde la salida de neovim 0.5 y la 
introducción de lua como lenguaje de "primera clase" tanto para configuración 
como para la creación de plugins, y en ese tiempo también hemos pasado por la 
versión 0.6, la 0.7, la 0.8, y al momento de escribir estas palabras estamos en 
la versión 0.8.2 estable y 0.9.x para las nightlies, y han habido muchísimos 
avances en todos los frentes.

¿Y que ha pasado con mi configuración? Que está escrita completamente en lua 
y ha visto varias iteraciones e idas y vueltas, como me caracteriza. Y todo ha 
funcionado mejor y ha funcionado peor y ha sido hecho de cero y de una y todo 
otra vez de nuevo algunas veces, tiempos capitalistas mediante.
Y se puede ver todo este progreso, como siempre, en mi cuenta de git de 
tildeverse. Mi plan era que estas cosas estuvieran en el git de texto-plano, por 
supuesto, pero dificultades técnicas mediantes tuvieron que quedarse en la 
instancia de gitea de tildeverse, que funciona muy bien y es de un bonito color 
verde.

No voy a ponerme a hablar de las idas y vueltas de cada una de las opciones 
y cosas que configuré y recontra configuré (bueno, tal vez un poco), sino del 
estado y ambiente general de como hacer que todo ande.

Como es de esperarse de la comunidad de usuarios de neovim, han salido mil y un 
instructivos en texto y en vídeo mejores y peores al respecto de todas estas 
cuestiones.
Las primeras fueron sobre la migración, claramente. Y es que lua realmente ha 
logrado que sea todo mas bonito e interesante que el inescrutable vimscript (que 
también ha recibido actualizaciones a merced de la versión 9 de vim, pero eso no 
es algo de lo que pueda escribir), pero también ha hecho que algunas cosas se 
expresen de maneras completamente diferentes, a veces un poco más elaboradas, 
pero en todos los casos más claras. También hubieron muchos artículos que fueron 
requiriendo actualizaciones, ya que no todas las funciones de neovim estaban 
expuestas en la interfaz de lua así que había que hacer un poquito de trampa 
y tener resabios de vimscript embebidos pero en estos tiempos eso ya es cosa del 
pasado.

La segunda (y actual) oleada de guias fueron para configurar el uso nativo de 
LSP. Ya no es necesario usar el pesado y engorroso coc (aunque alguna gente lo 
sigue haciendo), y hasta ni siquiera hace falta configurar demasiado o incluso 
instalar nada gracias a plugins como lsp-zero y la dupla mason 
y mason-lspconfig.
También han proliferado mucho esas "distribuciones con baterías incluidas" (como 
les suelen decir), que están listas para usar desde el primer momento.

Lo que todo esto ha logrado, sin embargo, es que hayan una serie de estándares 
de facto a la hora de configurar neovim sin hacer demasiada bulla. Con solo 
copiar algunas lineas y ponerlas en determinado archivo y reiniciar un par de 
veces el editor, o bien clonando un repositorio de git a la ruta ~/.config/nvim 
ya estaría todo solucionado.

Esto es algo que a mi me termina cayendo bastante mal por varias razones.
En el caso de las "distribuciones" lo que suele haber es una montaña de código 
espagueti de funciones de carga y precarga para "optimizar" (con muchas más 
comillas de las que me dan ganas de poner) la carga rápida/condicional/lo que 
sea de una parva de plugins que tal vez no nos interesen o no se apliquen 
a nuestros casos de uso, varias opciones que tal vez nos den ganas de cambiar, 
una paleta de colores decididamente horrible (y siempre pero siempre basada en 
tonos de azul), y varias otras cosas.
¿Que nos queda por hacer entonces? O bien desenmarañar el código, o bien crear 
otra maraña sobre todo eso con configuraciones que le sirven a uno, o bien ir 
a ver si algún alma caritativa creo un issue en github, o bien crearlo uno 
mismo.
En el caso de simplemente copiar 2 o 3 archivos de configuración pasa algo más 
o menos parecido pero con bastante menos código inútil, con lo cual emparchar la 
cuestión y hacer que la configuración sea nuestra es mas rápido.
Uno de los problemas aquí seria lsp-zero. Reescribir partes de la configuración 
es posible y no es tan enroscado como uno creería que es, pero sigue sin ser 
ideal. Por suerte el autor de este plugin aclara en su pagina de github que "tal 
vez no necesites lsp-zero" y da varias explicaciones a tal fin. Punto para él, 
bien hecho.

Otro de los problemas es mason. Mason es un plugin que lo que hace es instalar 
binarios en nuestro sistema en una de las carpetas de configuración de neovim 
y luego mediante mason-lspconfig se usan esas rutas para llamar a los servidores 
de LSP propiamente dichos según el tipo de archivo.
Esto, como ya dije cuando me referí a fzf.vim, es una pelotudez y un 
despropósito y simplemente esta MAL.
La manera correcta es instalar lo que vamos a usar desde el administrador de 
paquetes de nuestra distribución, o como mucho, usar un npm bien configurado 
llegado el caso. No tener binarios revoleados por ahí como si fuéramos usuarios 
de windows y los programas que descargamos de vaya uno a saber donde a su vez 
instalen programas descargados de vaya uno a saber donde y que quedan instalados 
en alguna carpeta ignota haciendo vaya uno a saber que.

Con lo cual tenemos que sí, son soluciones rápidas y que hacen que todo 
funcione, pero como suele pasar con esta clase de soluciones, terminan siendo 
una mierda. Y como dije mas arriba, se están convirtiendo en estándares de facto 
y eso No Es Bueno.

Siempre va a ser mucho mas fácil y rápido y provechoso configurar todo uno 
mismo, aprovechar lo mas que se puedan las cualidades que ya vienen en el editor 
(que son muchas y muy buenas), y usar la menor cantidad de estos estándares de 
facto posible. Todo esto tratando de llegar a un punto medio sano. Hay cosas que 
en definitiva son mucho mas cómodas como plugins (como por ejemplo packer).

Siguiendo por esta linea de llegar a un punto medio sano, hay una serie de 
plugins que prácticamente toda instalación de neovim tiene hoy por hoy. Me 
refiero a telescope y treesitter, y para los usuarios de LSP se agregan 
nvim-lspconfig, nvim-cmp, y casi seguramente null-ls.
Con estos 5 y el ya mencionado packer se puede hacer muchísimo y disfrutar de un 
montón de cualidades y tener un entorno de programación que con algunos 
adicionales mas (como algunos plugins que son agregados para nvim-cmp 
principalmente, entre otros), y una paleta de colores decente 
(cofcofgruvboxcofcof) funciona mejor y no tiene nada que envidiar a vscode 
o cosas por el estilo.

Pero, dirán ustedes, ¿cómo se configuran esos 5 plugins?. Y yo les respondo que 
todos traen una muy amplia documentación la cual deberían leer y aprovechar.
Y si aun así les resulta muy trabajoso todo, usen kickstart.nvim. Creado por uno 
de los desarrolladores principales del proyecto, en ese único archivo van 
a encontrar todo lo que necesitan para empezar a usar y, si les place, seguir 
usando nvim hasta que vuelva a ser hora de reconfigurar todo y empezar de nuevo.
Y dependiendo de sus niveles de aburrimiento y tiempo disponible, esto puede ser 
muy pronto.