Por qué existe LSP: N editores por M lenguajes

Durante dos décadas, cada editor que quiso ofrecer autocompletado semántico, salto a definición o renombrado seguro tuvo que implementar, dentro de sí mismo, un analizador para cada lenguaje que pretendiera soportar. Eso no era pereza ni mala arquitectura: era la única opción disponible, porque el conocimiento sobre un lenguaje vivía en el compilador y el compilador no exponía nada utilizable en tiempo de edición. El resultado fue un desperdicio industrial de proporciones asombrosas: el mismo análisis de resolución de nombres de Java, escrito una vez para Eclipse, otra para IntelliJ, otra para NetBeans, otra para Emacs, otra para Vim, cada una con sus propios fallos, su propia latencia y su propia noción incompleta de qué es un símbolo. El Language Server Protocol no inventó ningún algoritmo nuevo. Lo que hizo fue observar que ese problema tenía forma de producto cartesiano, y que un producto cartesiano se rompe introduciendo una interfaz en el medio.

El producto cartesiano

Sea N el número de editores que quieren ofrecer inteligencia de código y M el número de lenguajes que merecen soporte. Sin protocolo común, el trabajo total de integración es N x M: cada pareja necesita una implementación específica, porque el editor debe conocer la estructura interna del analizador y el analizador debe conocer las estructuras de datos del editor. Con veinte editores relevantes y cuarenta lenguajes vivos, son ochocientas integraciones. En la práctica nunca se construyeron ochocientas: se construyeron unas pocas decenas, y el resto del espacio quedó vacío. Esa es la forma real en que el problema se manifestaba —no como coste insoportable, sino como ausencia silenciosa de funcionalidad para casi todas las combinaciones—.

La observación central de LSP es que si se define una interfaz en el medio, el trabajo pasa de N x M a N + M. Cada editor la implementa una vez, del lado del cliente. Cada lenguaje la implementa una vez, del lado del servidor. Veinte más cuarenta son sesenta piezas en lugar de ochocientas, y —lo más importante— cada pieza nueva que aparece se conecta automáticamente con todas las del otro lado. Cuando alguien publica un servidor para un lenguaje nuevo, ese lenguaje adquiere el mismo día soporte en todos los editores que hablan el protocolo. Esa propiedad, la de que el valor marginal de cada implementación sea proporcional al tamaño del otro conjunto, es lo que convierte el diseño en un efecto de red.

flowchart LR
subgraph antes
  e1[editor 1] --- l1[lenguaje 1]
  e1 --- l2[lenguaje 2]
  e2[editor 2] --- l1
  e2 --- l2
end
subgraph despues
  e3[editor 1] --> p[protocolo]
  e4[editor 2] --> p
  p --> s1[servidor 1]
  p --> s2[servidor 2]
end
style p fill:#a6e3a1,color:#11111b

Conviene precisar que la reducción no es exactamente a N + M, porque cada cliente sigue necesitando saber cómo arrancar cada servidor: qué ejecutable invocar, con qué argumentos, qué ficheros marcan la raíz del proyecto y qué opciones específicas admite. Ese residuo de conocimiento por pareja es real, pero es de una naturaleza completamente distinta —configuración declarativa, no lógica de análisis— y por eso se deja externalizar a un catálogo compartido. Neovim expone ese catálogo como configuración de datos pura.

-- El residuo de conocimiento por pareja: puro dato declarativo.
vim.lsp.config["luals"] = {
  cmd = { "lua-language-server" },
  filetypes = { "lua" },
  root_markers = { ".luarc.json", ".git" },
  settings = { Lua = { runtime = { version = "LuaJIT" } } },
}

vim.lsp.enable("luals")

Dónde corta la frontera

Una interfaz solo funciona si el corte está en el sitio correcto, y el sitio correcto no era obvio. La decisión de diseño más importante de LSP fue colocar la frontera de manera que el servidor no sepa absolutamente nada sobre interfaz de usuario. El servidor no dibuja un menú de completado, no sabe qué es una ventana flotante, no decide si los diagnósticos aparecen como subrayado ondulado o como signos en la columna lateral. Su universo se reduce a documentos identificados por una URI, posiciones expresadas como pares de línea y carácter, y respuestas estructuradas en un formato serializable.

Simétricamente, el cliente no sabe nada sobre el lenguaje. Neovim no conoce la regla de resolución de sobrecargas de C++ ni el sistema de tipos de Rust: recibe una lista de candidatos con etiquetas y fragmentos de texto, y su única responsabilidad es presentarlos y aplicar la edición que el usuario elija. Esta ignorancia mutua es deliberada y es la fuente de toda la robustez del sistema. Un cliente escrito hoy funciona con un servidor publicado dentro de cinco años para un lenguaje que aún no existe, porque ninguna de las dos partes hizo suposiciones sobre la otra más allá del contrato.

El vocabulario que cruza la frontera es sorprendentemente reducido. La unidad atómica es la posición, un par de enteros; el rango es un par de posiciones; la localización es un rango con una URI. Casi todo lo demás del protocolo se construye componiendo esas tres formas.

{
  "uri": "file:///home/dev/proyecto/src/main.rs",
  "range": {
    "start": { "line": 41, "character": 8 },
    "end":   { "line": 41, "character": 19 }
  }
}

El coste de la separación

Convertir el analizador en un proceso separado no es gratis, y conviene tener presente la factura. Primero, hay serialización: cada consulta implica convertir estructuras en memoria a texto, transmitirlas por una tubería y reconstruirlas al otro lado. Segundo, hay asincronía obligatoria: el editor no puede bloquearse esperando, así que toda la funcionalidad se vuelve una promesa que puede tardar, fallar o llegar cuando el usuario ya movió el cursor. Tercero, hay duplicación de estado: el servidor mantiene su propia copia del contenido de cada fichero abierto, y esa copia puede desincronizarse de la del editor —de hecho, la mayoría de los fallos desconcertantes de LSP en producción son exactamente eso—.

A cambio, se obtiene aislamiento. Un servidor que consume memoria sin control o que entra en bucle infinito no arrastra al editor consigo: se reinicia el proceso y la sesión de edición sobrevive. Un servidor escrito en el lenguaje que analiza —el caso habitual, porque quien mejor conoce un lenguaje es su propio compilador— puede reutilizar la infraestructura real del compilador en lugar de reimplementarla. Y la frontera de proceso permite que el servidor lo escriba el equipo del lenguaje mientras el cliente lo escribe el equipo del editor, sin coordinación entre ambos más allá de la especificación.

-- El aislamiento es observable: el proceso se puede inspeccionar y reiniciar
-- sin que la sesion de edicion se entere de nada.
for _, cliente in ipairs(vim.lsp.get_clients()) do
  print(cliente.name, cliente.id, cliente.root_dir)
end

vim.api.nvim_create_user_command("LspReiniciar", function()
  for _, c in ipairs(vim.lsp.get_clients({ bufnr = 0 })) do
    c:stop()
  end
  vim.defer_fn(function() vim.cmd("edit") end, 200)
end, {})

Hay una última consecuencia que suele pasar desapercibida y que explica muchas frustraciones. Como el protocolo es el mínimo común denominador de todos los lenguajes posibles, sus estructuras de datos son deliberadamente pobres: un símbolo tiene un nombre, un tipo tomado de una enumeración fija y un rango, pero no tiene genéricos, ni visibilidad, ni pertenencia a un módulo, porque no todos los lenguajes tienen esos conceptos. Cuando echas de menos una función que tu entorno anterior hacía, muchas veces no es que el servidor no sepa la respuesta: es que el protocolo no tiene una casilla donde ponerla.

El ecosistema que la interfaz hizo posible

La prueba de que el corte estaba bien situado no es teórica sino histórica: apareció una clase entera de componentes que nadie había planeado. Como el cliente solo sabe hablar el protocolo y no le importa quién esté al otro lado, cualquier programa que hable el protocolo puede ocupar ese puesto aunque no sea un analizador de lenguaje. De ahí nacieron los servidores puente, que envuelven herramientas antiguas de línea de órdenes —linters, formateadores, correctores ortográficos— y traducen su salida a diagnósticos y acciones de código. Ninguna de esas herramientas fue diseñada para editores, y sin embargo hoy se integran igual de bien que un compilador moderno.

La misma indiferencia funciona en la otra dirección. Como el servidor no sabe quién le pregunta, un proceso intermedio puede sentarse entre ambos, reenviar los mensajes y aprovechar el paso para registrarlos, transformarlos o repartirlos entre varios servidores. Esa arquitectura de intermediario transparente —imposible si el analizador fuese una biblioteca enlazada dentro del editor— es la que permite depurar el tráfico, multiplexar un mismo servidor entre varias ventanas o parchear un comportamiento defectuoso sin tocar ninguno de los dos extremos.

-- Nada en la configuracion revela si al otro lado hay un compilador,
-- un envoltorio sobre una herramienta antigua o un intermediario.
vim.lsp.config["puente"] = {
  cmd = { "efm-langserver" },
  filetypes = { "markdown", "sh", "yaml" },
  root_markers = { ".git" },
}

-- Varios clientes adjuntos al mismo buffer: la pregunta correcta nunca es
-- que soporta el servidor, sino que soporta alguno de los adjuntos.
local function alguno_soporta(metodo)
  for _, c in ipairs(vim.lsp.get_clients({ bufnr = 0 })) do
    if c:supports_method(metodo) then return c end
  end
end

Ese es el rendimiento compuesto de una interfaz bien colocada: no solo reduce el trabajo previsto, sino que habilita usos que su autor no imaginó. Ninguna de estas piezas requirió permiso, coordinación ni cambios en la especificación, porque todas se limitan a cumplir el mismo contrato que ya existía.