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

[umutondersu]

Summary

• Added support for the new LSP configuration API introduced in Neovim 0.11+
• Updated Mason version to v2

[ro0gr]

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]

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]

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]

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 ✌️

[umutondersu]

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

[kaezrr]

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]

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

[umutondersu]

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.

[pandar00]

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]

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]

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.

[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 {}),
      }

[Graeme22]

My config was broken until I added the changes from this PR. As far as I understand Mason v2 doesn't support the handler approach that was being used before, so none of my LSP configuration was actually being applied.

[Mithrandir2k18]

If this PR aims to only support nvim 0.11+, then it maybe also should remove the client_supports_method function?

[Mithrandir2k18]

Also, maybe I'm just blind, I didn't checkout the PR, but this name variable seems undefined?

Edit: my bad, I thought I was on the forks commit list, not on the PRs, where the commit order is inverted.

[umutondersu]

@Mithrandir2k18

If this PR aims to only support nvim 0.11+, then it maybe also should remove the client_supports_method function?

I started the PR supporting older versions as well, However most people thought it wasn't necessary because kickstart only support the latest neovim version and having cleaner code would be better for beginners.

I didn't touch the clients_supports_method as this pr is only focused on the new LSP API of neovim

Also, maybe I'm just blind, I didn't checkout the PR, but this name variable seems undefined?

It has been fixed. You are looking at an older version of the branch

[spundun]

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.

I personally love to keep the code free of legacy dependencies, but Ubuntu, Debian and some Fedoras don't yet have 0.11 , maybe someone familiar with the code could contribute an upgrade to the most common distros?

https://packages.ubuntu.com/search?keywords=neovim&searchon=names&suite=plucky&section=all

https://packages.debian.org/search?keywords=neovim&searchon=names&suite=stable&section=all

https://packages.fedoraproject.org/pkgs/neovim/neovim/

[guru245]

Hi @spundun ,

Neovim also provides a prebuilt package: AppImage and tarball. We don't have to build Neovim for the distrubution. Please check out this link: https://github.com/neovim/neovim/releases/tag/v0.11.2

[spundun]

Hi @guru245 , Thanks for the response. That's a cool new thing I learned today :).

The README.md just says "If you are experiencing issues, please make sure you have the latest versions.". Since kickstart puts priority on being new-user-friendly, I'd suggest you add more detailed guidelines there. To many users, "make sure you have the latest version" might just mean making sure you have all the latest software updates from your package manager, especially if you're on the latest version of some standard OS.

Maybe adding detailed instructions along the lines... if nvim --version reports a version lower than the Required version then here are the instructions on how to install it in the user-file-system and set it as your editor before you begin.

[mybuddymichael]

I spent way too long trying to figure out why inlay hints wouldn't appear anywhere! Turns out my LSP settings weren't even being loaded. I'm super glad I found this PR!