LSP nativo: el cerebro del IDE

El LSP es lo que convierte a Neovim en un IDE: autocompletado semántico, ir a definición, renombrado seguro, diagnósticos en tiempo real y refactors. En Neovim 0.12 todo eso vive en el núcleo: describes cada servidor en un fichero, lo activas con una línea, y no necesitas ningún plugin para que funcione.

Qué es el LSP

El Language Server Protocol separa la inteligencia del lenguaje del editor. Un “language server” (p. ej. rust-analyzer, clangd, lua_ls) es un proceso independiente que entiende tu código y responde preguntas: “¿dónde se define esto?”, “¿qué autocompleta aquí?”, “¿hay errores?”. Neovim es el cliente que le pregunta.

flowchart LR
N[Neovim cliente LSP] -->|peticiones| S[Servidor de lenguaje]
S -->|diagnosticos completado definiciones| N
M[Gestor de binarios opcional] -.instala.-> S
style N fill:#89b4fa,color:#11111b
style S fill:#cba6f7,color:#11111b
style M fill:#a6e3a1,color:#11111b

La forma nativa: describir y activar

En 0.12 configurar un servidor son dos gestos separados. vim.lsp.config describe un servidor: qué binario lanzar (cmd), para qué tipos de fichero (filetypes), qué marca la raíz del proyecto (root_markers) y qué opciones enviarle (settings). vim.lsp.enable lo activa: a partir de ahí, cuando abras un buffer del tipo adecuado, Neovim resuelve la raíz, arranca el proceso y adjunta el cliente.

Puedes llamar a vim.lsp.config desde tu init.lua, pero la forma canónica es otra: cualquier fichero lsp/nombre.lua dentro del runtimepath se interpreta como la configuración del servidor nombre, y solo se lee cuando ese servidor hace falta. Un fichero por servidor, y el arranque se queda con una sola línea.

-- Devuelve la tabla; no llames a vim.lsp.config desde aquí.
return {
  cmd = { "lua-language-server" },
  filetypes = { "lua" },
  -- La lista nested indica "igual prioridad": cualquiera de los dos vale.
  root_markers = { { ".luarc.json", ".luarc.jsonc" }, ".git" },
  settings = {
    Lua = {
      runtime = { version = "LuaJIT" },
      workspace = { checkThirdParty = false },
      telemetry = { enable = false },
    },
  },
}

return {
  cmd = { "clangd", "--background-index", "--clang-tidy" },
  filetypes = { "c", "cpp", "objc", "objcpp" },
  root_markers = { "compile_commands.json", ".clangd", ".git" },
}

-- Una sola línea decide qué se activa.
vim.lsp.enable({
  "lua_ls",       -- Lua (tu config)
  "clangd",       -- C / C++
  "ts_ls",        -- TypeScript / JavaScript
  "tailwindcss",
  "cssls", "html", "jsonls", "yamlls",
})

Lo transversal —lo que quieres para todos los servidores— se declara una vez bajo el nombre comodín *:

vim.lsp.config("*", {
  root_markers = { ".git" },
  capabilities = {
    textDocument = { semanticTokens = { multilineTokenSupport = true } },
  },
})

nvim-lspconfig y Mason: qué aportan hoy

Ninguno de los dos es necesario. Conviene saber exactamente qué hace cada uno para decidir con criterio.

nvim-lspconfig ya no es una capa, es un catálogo. El repositorio contiene hoy un directorio lsp/ con centenares de ficheros como los que acabas de escribir a mano, mantenidos por gente que ha averiguado qué argumento necesita cada binario, qué marcadores identifican la raíz de cada ecosistema y qué tipos de fichero reclama cada servidor. Al instalarlo, ese directorio entra en tu runtimepath y sus fichas quedan disponibles con menor precedencia que las tuyas. No aporta mecanismo: sigues escribiendo vim.lsp.config y vim.lsp.enable. Lo instalas si trabajas con muchos lenguajes y no quieres averiguar los detalles de cada uno; lo omites si tu abanico es corto.

return {
  "neovim/nvim-lspconfig",
  lazy = false,  -- son datos en el runtimepath: nada que cargar en diferido
}

vim.pack.add({ { src = "https://github.com/neovim/nvim-lspconfig" } })

Mason resuelve un problema distinto y ortogonal: conseguir el binario. Instala servidores, formateadores y depuradores en un directorio propio y lo añade al camino de búsqueda de ejecutables. Ni declara ni activa nada; solo hace que el cmd de tus fichas exista en la máquina. Si instalas tus servidores con el gestor de paquetes del sistema (brew, apt, npm, cargo), no lo necesitas.

return {
  "mason-org/mason.nvim",
  lazy = false,
  priority = 100,  -- el PATH debe estar listo antes del primer LspAttach
  opts = {},
}

vim.pack.add({ { src = "https://github.com/mason-org/mason.nvim" } })

require("mason").setup({})

Novedades de 0.12 que vas a notar

Keymaps: mapea solo lo que falta

Este es el cambio de hábito más grande. Neovim 0.12 crea atajos globales de LSP y de diagnósticos al arrancar, sin que configures nada:

Con eso claro, lo que queda por mapear es poco. Los atajos que dependen del LSP viven en el evento LspAttach, que es el único momento en que existen buffer y cliente:

vim.api.nvim_create_autocmd("LspAttach", {
  group = vim.api.nvim_create_augroup("lsp_attach", { clear = true }),
  callback = function(ev)
    local client = vim.lsp.get_client_by_id(ev.data.client_id)
    if not client then return end

    local map = function(keys, fn, desc)
      vim.keymap.set("n", keys, fn, { buffer = ev.buf, desc = "LSP: " .. desc })
    end

    -- Solo lo que Neovim no trae ya mapeado
    map("<leader>lf", function() vim.lsp.buf.format({ timeout_ms = 2000 }) end, "Formatear")
    map("<leader>lw", vim.lsp.buf.workspace_symbol, "Buscar simbolo en el proyecto")
    map("<leader>ld", vim.diagnostic.setqflist, "Diagnosticos al quickfix")

    -- Inlay hints (tipos en linea): estan apagados por defecto
    if client:supports_method("textDocument/inlayHint") then
      vim.lsp.inlay_hint.enable(true, { bufnr = ev.buf })
      map("<leader>lh", function()
        local on = vim.lsp.inlay_hint.is_enabled({ bufnr = ev.buf })
        vim.lsp.inlay_hint.enable(not on, { bufnr = ev.buf })
      end, "Alternar inlay hints")
    end

    -- Code lens: tambien apagado por defecto; se dibuja como lineas virtuales
    if client:supports_method("textDocument/codeLens") then
      vim.lsp.codelens.enable(true, { bufnr = ev.buf })
    end
  end,
})

Diagnósticos con estilo

Configura cómo se ven los errores y avisos. Esto no depende del LSP: vim.diagnostic es un subsistema propio y el cliente es solo uno de sus productores.

vim.diagnostic.config({
  virtual_text = { severity = { min = vim.diagnostic.severity.WARN }, prefix = "●" },
  virtual_lines = { current_line = true },   -- el mensaje completo, solo en la linea del cursor
  underline = true,
  update_in_insert = false,
  severity_sort = true,
  float = { border = "rounded", source = true },
  signs = {
    text = {
      [vim.diagnostic.severity.ERROR] = " ",
      [vim.diagnostic.severity.WARN]  = " ",
      [vim.diagnostic.severity.HINT]  = " ",
      [vim.diagnostic.severity.INFO]  = " ",
    },
  },
})

Plugins que hacen el LSP aún mejor

Ninguno hace falta para que el LSP funcione. Estos tres se ganan el sitio por otras razones.

return {
  "folke/lazydev.nvim",
  ft = "lua",
  opts = {
    library = { { path = "${3rd}/luv/library", words = { "vim%.uv" } } },
  },
}

vim.pack.add({ { src = "https://github.com/folke/lazydev.nvim" } })

require("lazydev").setup({
  library = { { path = "${3rd}/luv/library", words = { "vim%.uv" } } },
})