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.