feat: add support for new LSP config API in Neovim 0.11+ #1475

umutondersu · 2025-04-16T17:39:11Z

Summary

Added support for the new LSP configuration API introduced in Neovim 0.11+
Maintains backward compatibility for Neovim 0.10 and below

ro0gr · 2025-04-17T10:28:39Z

Kickstart.nvim targets only the latest 'stable' and latest 'nightly' of Neovim.

Do we really need backward compatibility with Neovim 0 10? I'd consider going with a lighter, happy-path solution. Since the project mainly targets newcomers and servers educational purposes, they'd likely prefer to avoid dealing with legacy approaches.

umutondersu · 2025-04-17T11:08:05Z

I think that would be the right approach as well. The reason I intended to maintain backwards compatibility is that some parts of the code is still trying to maintain 0.10 like the client_supports_method. Depending on the others reaction I would also be in favor of removing it.

umutondersu · 2025-04-17T12:44:00Z

There is also the problem new syntax not supporting all lsp configs. For example tailwindcss requires the old setup. Could be a good idea to delay this until most lsp configs migrate.

nickgnd · 2025-04-17T13:18:51Z

Hey everyone 👋
I remember a few related conversations that happen lately on this topic, let me share them here

#1458
#1331

I hope they can be useful, cheers ✌️

init.lua

umutondersu · 2025-04-17T15:14:56Z

Hey everyone 👋 I remember a few related conversations that happen lately on this topic, let me share them here

#1458 #1331

I hope they can be useful, cheers ✌️

This setup config does not clash with blink.cmp so in that sense It should be okay.
I would be able to support this in an ongoing basis
I think using the native way would provide a better experience for newbies but that's up to debate

Signed-off-by: Umut Sahin Onder <[email protected]>

kaezrr · 2025-04-20T04:41:56Z

In my opinion, we shouldn't bother with backwards compatibility since Kickstart is mostly aimed at beginners who will download the latest version of Neovim as per the instructions in the repo readme

umutondersu · 2025-04-20T11:06:46Z

I have removed backwards compatibility and added useful comments for LSPs that still require the old setup

init.lua

umutondersu · 2025-04-24T10:18:55Z

Messing around with this and found that this will not respect the lsp_format = "fallback" option in the conform.nvim config. To replicate:
1. comment out the stylua formatter line from conform.nvim config

2. save and reload neovim

3. overindent a line or any other formatting change

4. write file
For me it did not fallback on the lua_ls server for formatting.

I couldn't replicate the issue. I do not think it would be related to these changes as conform.nvim does not use an LSP. In any case If you could check your conform logs by using :ConformInfo It could reveal more info about the issue.

init.lua

Co-authored-by: Rory Hendrickson <[email protected]>

- nvim-lua/kickstart.nvim#1475

1Naim · 2025-05-07T09:43:12Z

init.lua

        automatic_installation = false,
        handlers = {
          function(server_name)
-            local server = servers[server_name] or {}
-            -- This handles overriding only values explicitly passed
-            -- by the server configuration above. Useful when disabling
-            -- certain features of an LSP (for example, turning off formatting for ts_ls)
-            server.capabilities = vim.tbl_deep_extend('force', {}, capabilities, server.capabilities or {})
-            require('lspconfig')[server_name].setup(server)
+            local config = servers[server_name] or {}
+            vim.lsp.config(server_name, config)
+            vim.lsp.enable(server_name)
          end,


mason-lspconfig.nvim v2.0.0 removes this now. It auto-enables installed LSPs if they're using the new vim.lsp.* API. See https://github.com/mason-org/mason-lspconfig.nvim/releases/tag/v2.0.0

1Naim · 2025-05-07T09:58:53Z

init.lua

+        for server, config in pairs(servers) do
+          -- This handles overriding only values explicitly passed
+          -- by the server configuration above. Useful when disabling
+          -- certain features of an LSP (for example, turning off formatting for ts_ls)
+          config.capabilities = vim.tbl_deep_extend('force', {}, capabilities, server.capabilities or {})
+          vim.lsp.config(name, config)


I guess the original hunk of the patch is relevant (and should be used?) now.

Sorry I don't know how to mention lines, but shouldn't it be vim.lsp.config(server, config)? As well as vim.lsp.enable(server)

Yes that was fixed in a later commit in this PR, I was quoting from an earlier one.

pandar00 · 2025-05-10T08:28:29Z

AFAIK mason-lspconfig setting's handler is a no-op. (PR)
LSP settings are moved to after/lsp/<lang_server_name>.lua (credit; in JP)
lsp-config doc also explains the config is merged with the default.

Note: The merge semantics of configurations follow the behaviour of vim.tbl_deep_extend().

I've been updating my old neovim configs with the latest kickstart but the LSP settings weren't reflected in :LspInfo, but after following the above, LSP correctly reads them

umutondersu · 2025-05-10T17:09:12Z

AFAIK mason-lspconfig setting's handler is a no-op. (PR) LSP settings are moved to after/lsp/<lang_server_name>.lua (credit; in JP) lsp-config doc also explains the config is merged with the default.

Note: The merge semantics of configurations follow the behaviour of vim.tbl_deep_extend().

I've been updating my old neovim configs with the latest kickstart but the LSP settings weren't reflected in :LspInfo, but after following the above, LSP correctly reads them

If we were to move LSP configs to their own file, I don't know how mason-tool-installer would work without the servers table maybe by iterating over file names?

In your config I see that you still have the servers table. If It is still gonna be preset wouldn't be better to use vim.lsp.config with a loop (like my first hunk) rather than having 2 separate places for LSP servers?

umutondersu · 2025-05-10T17:13:46Z

As mentioned in previous conversations, Mason v2 has started introducing a significant delay during startup. For now, I’ve pinned the Mason version to avoid this issue.

From my testing, the problem appears to be related to mason-tool-installer; without it, I don’t experience any delays. It would be helpful to hear from someone with more insight into this before proceeding further with Mason v2.

shv187 · 2025-05-10T19:48:39Z

My personal temporary solution is to set debounce_hours in mason-tool-installer, to 24 in my case.

umutondersu · 2025-05-11T13:17:10Z

After the recent updates mason-tool-installer seems to not have this issue anymore. I will commit a change for Mason V2

init.lua

DanWlker · 2025-05-11T13:52:55Z

init.lua

+      -- Installed LSPs are configured and enabled automatically with mason-lspconfig
+      -- The loop below is for overriding the default configuration of LSPs with the ones in the servers table
+      for server_name, config in pairs(servers) do
+        vim.lsp.config(server_name, config)


Also, before all the servers work, should we just use require("lspconfig").server_name.setup{}? since that currently works for everything

@DanWlker - In my testing, the lsp server configs do not get merged with the defaults from lspconfig:

for server_name, server_config in pairs(servers) do require("lspconfig")[server_name].setup(server_config) end

Unless I am missing something.

I'm only using require("lspconfig").server_name.setup{}, not quite sure what you mean by lsp configs not getting merged

tienbg-zigexn · 2025-05-12T11:56:36Z

Currently I'm using the handlers in mason-lspconfig like this:

                handlers = {
                    function(server_name)
                        if server_name == "standardrb" or server_name == "rubocop" then
                            local personal_path = vim.fn.expand("~") .. "/programming/me"
                            local current_dir = vim.fn.getcwd()
                            local in_personal_project = string.find(current_dir, "^" .. personal_path) ~= nil

                            if
                                (server_name == "standardrb" and not in_personal_project)
                                or (server_name == "rubocop" and in_personal_project)
                            then
                                return
                            end
                        end

                        local server = servers[server_name] or {}

                        server.capabilities = vim.tbl_deep_extend("force", {}, capabilities, server.capabilities or {})
                        require("lspconfig")[server_name].setup(server)
                    end,
                },

The purpose is to load standardrb only in personal projects and rubocop on others. How can I migrate this into new version?

umutondersu · 2025-05-12T15:13:36Z

Currently I'm using the handlers in mason-lspconfig like this:

                handlers = {
                    function(server_name)
                        if server_name == "standardrb" or server_name == "rubocop" then
                            local personal_path = vim.fn.expand("~") .. "/programming/me"
                            local current_dir = vim.fn.getcwd()
                            local in_personal_project = string.find(current_dir, "^" .. personal_path) ~= nil

                            if
                                (server_name == "standardrb" and not in_personal_project)
                                or (server_name == "rubocop" and in_personal_project)
                            then
                                return
                            end
                        end

                        local server = servers[server_name] or {}

                        server.capabilities = vim.tbl_deep_extend("force", {}, capabilities, server.capabilities or {})
                        require("lspconfig")[server_name].setup(server)
                    end,
                },

The purpose is to load standardrb only in personal projects and rubocop on others. How can I migrate this into new version?

Mason-lspconfig enables all installed LSPs by default, You can disable individual LSPs with vim.lsp.enable(server_name,enable) instead of returning.

init.lua

Based on nvim-lua#1475

oriori1703

maybe you should only enable lsps that were installed using ensure_installed.
This way you will mirror the original behaviour.

i.e.

      ---@type MasonLspconfigSettings
      ---@diagnostic disable-next-line: missing-fields
      require('mason-lspconfig').setup {
        automatic_enable = vim.tbl_keys(servers or {}),
      }

SetsuikiHyoryu · 2025-05-17T16:56:06Z

init.lua

+      ---@type MasonLspconfigSettings
+      ---@diagnostic disable-next-line: missing-fields
+      require('mason-lspconfig').setup {
+        automatic_enable = vim.tbl_keys(servers or {}),


@umutondersu @oriori1703

I looked into the source code of mason-lspconfig. When the keys of servers are passed as a table to automatic_enable, it causes mason-lspconfig to ignore any LSPs that are installed via Mason but not explicitly listed in servers.

In the mason-lspconfig.nvim\doc\mason-lspconfig.txtmason-lspconfig.nvim\doc\mason-lspconfig.txt document, it mentions that doing this will only start certain servers:

-- To only enable certain servers to be automatically enabled: -- ```lua -- automatic_enable = { -- "lua_ls", -- "vimls" -- } -- ```

In the setup that in the mason-lspconfig.nvim\lua\mason-lspconfig\init.lua，if automatic_enable is not set to false, both enable_all and init will be executed:

function M.setup(config) if config then settings.set(config) end --- ... local registry = require "mason-registry" registry.refresh(vim.schedule_wrap(function(success, updated_registries) if success and #updated_registries > 0 and settings.current.automatic_enable ~= false then require("mason-lspconfig.features.automatic_enable").enable_all() end end)) if settings.current.automatic_enable ~= false then require("mason-lspconfig.features.automatic_enable").init() end -- ... end

In mason-lspconfig\features\automatic_enable.lua, The logic for enabling servers in init and enable_all is the same:

return { init = function() enabled_servers = {} _.each(enable_server, registry.get_installed_package_names()) -- We deregister the event handler primarily for testing purposes where .setup() is called multiple times in the -- same instance. registry:off("package:install:success", enable_server_scheduled) registry:on("package:install:success", enable_server_scheduled) end, enable_all = function() _.each(enable_server, registry.get_installed_package_names()) end, }

However, in enable_server, if automatic_enable is a table and an LSP installed by Mason is not listed in automatic_enable, it will not execute vim.lsp.config and vim.lsp.enable.

local function enable_server(mason_pkg) -- ... local lspconfig_name = mappings.get_mason_map().package_to_lspconfig[mason_pkg] -- ... local automatic_enable = settings.current.automatic_enable if type(automatic_enable) == "table" then local exclude = automatic_enable.exclude if exclude then if _.any(_.equals(lspconfig_name), exclude) then -- This server is explicitly excluded. return end else if not _.any(_.equals(lspconfig_name), automatic_enable) then -- This server is not explicitly enabled. return end end elseif automatic_enable == false then return end -- ... vim.lsp.enable(lspconfig_name) -- ... end

In other words, even if I’ve already installed the LSPs via Mason, I still have to list all the LSPs I use in servers or in or {}. Isn't that kind of ... not very "lazy"?

It seems you are right about automatic_enable.
If set to true it will enable all the LSPs, but when given a table it will only enable those LSPs.
After looking into it more, enabling all the LSPs also seems to be the old behaviour mason.

Despite that , I still prefer declarativly specifying all the LSPs in the config file, instead of downloading them using the mason interface.
This way I can commit those LSPs and have a reproducible setup.
This is the same reason I commit the lazy-lock.json file.

Though I guess this is a matter of taste, and could break setups for people that were used to the old way, so I'm ok with both options :)

@umutondersu @SetsuikiHyoryu what do you think?

@oriori1703 @umutondersu

Personally, I prefer the more “lazy” approach, but I tend to follow the method recommended by the Neovim official because I feel it’s more native. That means the operational habits won’t differ too much even when I have to work in a barebones environment. However, I’m not entirely sure what the official philosophy is on this. Judging from the existence of the vim.lsp.enable interface, it seems that the official intent is for LSP to be explicitly enabled.

Perhaps, if Mason provides an interface to retrieve the list of installed packages, a compromise could be to merge that list into the loop that calls vim.lsp.enable (the table passed to automatic_enable).

Sorry, it seems that
_.each(enable_server, registry.get_installed_package_names())
is already configuring only the installed packages. Setting automatic_enable = true doesn't appear to enable LSPs that haven't been installed.

umutondersu added 2 commits April 16, 2025 19:34

feat: add support for new LSP config API in Neovim 0.11+

3f0cd75

Typo fix

f70dcb3

yetyetanotherusername reviewed Apr 17, 2025

View reviewed changes

init.lua Outdated Show resolved Hide resolved

init.lua Outdated Show resolved Hide resolved

umutondersu added 2 commits April 17, 2025 17:17

fix(lsp): correct variable name in lsp config loop

4b81900

Signed-off-by: Umut Sahin Onder <[email protected]>

style: format with stylua

5502cea

fix(lsp): Remove backwards compatibility and add comments for lsp setup

a590ab6

umutondersu added 2 commits April 20, 2025 13:12

fix: Typo in comment

dac395d

fix: revert back to original handler logic

531073d

1Naim reviewed Apr 22, 2025

View reviewed changes

init.lua Outdated Show resolved Hide resolved

yetyetanotherusername approved these changes Apr 23, 2025

View reviewed changes

This comment was marked as resolved.

Sign in to view

This comment has been minimized.

Sign in to view

roryhen reviewed Apr 27, 2025

View reviewed changes

init.lua Outdated Show resolved Hide resolved

oriori1703 mentioned this pull request Apr 29, 2025

Replace outdated require('lspconfig')[server_name].setup() #1502

Open

Fix: correct variables inside comments

81c5210

Co-authored-by: Rory Hendrickson <[email protected]>

michaellisitsa added a commit to michaellisitsa/dotfiles that referenced this pull request May 5, 2025

Use neovim v0.11 lsp capabilities

e917ad0

- nvim-lua/kickstart.nvim#1475

1Naim reviewed May 7, 2025

View reviewed changes

fix(deps): pin mason plugin versions to v1.*

9e0c7b6

umutondersu and others added 2 commits May 11, 2025 15:18

feat(lsp): Update Mason to v2

0018683

Merge branch 'master' into master

f9628e5

DanWlker reviewed May 11, 2025

View reviewed changes

init.lua Outdated Show resolved Hide resolved

DanWlker reviewed May 11, 2025

View reviewed changes

fix: mason server name

718c90d

nickgnd mentioned this pull request May 12, 2025

fix(mason-lspconfig): add missing field automatic_enable in setup #1527

Closed

oriori1703 approved these changes May 12, 2025

View reviewed changes

This was referenced May 13, 2025

ltex-ls-plus settings are not passed to LSP-Server #1525

Closed

Unable to use lsp dependent keymaps #1517

Closed

carloscalla reviewed May 15, 2025

View reviewed changes

init.lua Show resolved Hide resolved

awcot mentioned this pull request May 15, 2025

LSP configuration settings not being passed #1543

Closed

1 task

oriori1703 added a commit to oriori1703/kickstart-modular.nvim that referenced this pull request May 15, 2025

add support for new LSP config API in Neovim 0.11+

ec42957

Based on nvim-lua#1475

oriori1703 suggested changes May 15, 2025

View reviewed changes

Refactor(lsp): Ensure automatic server enabling

82949b8

umutondersu requested a review from oriori1703 May 17, 2025 11:57

oriori1703 approved these changes May 17, 2025

View reviewed changes

SetsuikiHyoryu reviewed May 17, 2025

View reviewed changes

feat: add support for new LSP config API in Neovim 0.11+ #1475

Are you sure you want to change the base?

feat: add support for new LSP config API in Neovim 0.11+ #1475

Uh oh!

Conversation

umutondersu commented Apr 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

ro0gr commented Apr 17, 2025

Uh oh!

umutondersu commented Apr 17, 2025

Uh oh!

umutondersu commented Apr 17, 2025

Uh oh!

nickgnd commented Apr 17, 2025

Uh oh!

Uh oh!

Uh oh!

umutondersu commented Apr 17, 2025

Uh oh!

kaezrr commented Apr 20, 2025

Uh oh!

umutondersu commented Apr 20, 2025

Uh oh!

Uh oh!

This comment was marked as resolved.

umutondersu commented Apr 24, 2025

Uh oh!

This comment has been minimized.

Uh oh!

1Naim May 7, 2025

Choose a reason for hiding this comment

Uh oh!

1Naim May 7, 2025

Choose a reason for hiding this comment

Uh oh!

shv187 May 8, 2025

Choose a reason for hiding this comment

Uh oh!

1Naim May 9, 2025

Choose a reason for hiding this comment

Uh oh!

pandar00 commented May 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

umutondersu commented May 10, 2025

Uh oh!

umutondersu commented May 10, 2025

Uh oh!

shv187 commented May 10, 2025

Uh oh!

umutondersu commented May 11, 2025

Uh oh!

Uh oh!

DanWlker May 11, 2025

Choose a reason for hiding this comment

Uh oh!

pbnj May 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DanWlker May 17, 2025

Choose a reason for hiding this comment

Uh oh!

tienbg-zigexn commented May 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

umutondersu commented May 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

oriori1703 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SetsuikiHyoryu May 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

umutondersu commented Apr 16, 2025 •

edited

Loading

pandar00 commented May 10, 2025 •

edited

Loading

pbnj May 16, 2025 •

edited

Loading

tienbg-zigexn commented May 12, 2025 •

edited

Loading

umutondersu commented May 12, 2025 •

edited

Loading

oriori1703 left a comment •

edited

Loading

SetsuikiHyoryu May 17, 2025 •

edited

Loading

SetsuikiHyoryu May 23, 2025 •

edited

Loading