vim-lsp 2022

[prabirshrestha]

It is the time of the year to go back to the community and ask what you would like to see in vim-lsp going forward in 2022. I have done similar posts in the past vim-lsp 2020 and vim-lsp 2021 (poll).

Please use one comment for each suggestion. If you want to expand on it use the replies. Use the thumbs-up and thumbs-down to express whether you agree with a specific answer/request (you can find that in the header of the comment on the top right, looks like a smiley face). Looking at the latest LSP spec we seem to have most of the features in vim-lsp except few big ones. There are also lots of possibilities for small user and ux improvements that I have in mind but as last year I want to see what you think is a top priority.

Last year we made a lot of perf improvements (not done yet), internal refactor, improved stability and added tons of new features.

For the first time we opened up donations and had some contributions. If you are enjoying vim-lsp feel free to checkout https://opencollective.com/vim-lsp or individually donate to contributors of your choice.

Happy New Year!

[jmdevin]

Sometime this year, I think it would be wise to begin writing some features in vim9script. Vim9script can be mixed with legacy vimscript in the same file. While vim 9 itself has not been released yet, it shouldn't be too far off as Bram indicates the syntax and implementation are stable. The feature itself has been added already for testing. When vim 9 is eventually released and trickles down to the stable repos, this would result in a big performance gain for anyone who can't take advantage of lua.

[jmdevin]

This is a list of goals for 2022, not for January 3rd from what I understand, so I don't think it's premature when vim 9 will be out with plenty of time left in the year. Vim9script, unlike lua, will eventually ship with vim by default on popular distros. After that happens, there might not be a reason for bottlenecking code to be written in legacy vimscript at all, meaning only two implementations. Or one, if neovim decides to support vim9script.

[idbrii]

there might not be a reason for bottlenecking code to be written in legacy vimscript at all

This assumes that vim-lsp should drop support for older versions of vim.

[jmdevin]

Eventually, I imagine that would happen, yes. Once vim 9 is the version you get on Ubuntu LTS, maybe. But it's certainly not required to add vim9script support in the first place. The unlikely event that neovim supports vim9script would certainly make things easier.

[Guergeiro]

I do agree with @jmdevin. vim9script would be a nice to be added, specially after it becomes the default on Debian/Ubuntu.

I know @prabirshrestha already said he wouldn't support it, although personally I feel like the reason behind it is irrelevant since neovim now has its own lsp ecosystem.

[prabirshrestha]

I have not found the use of vim9script help improve perf yet, because most of the bottlenecks are better being implemented in vim core in c which will be even faster than implementing in vim9script.

For example:

• fuzzy searching: matchfuzzy was added to vim.
• lsp client in vim-lsp is quite slow. Vim now supports native LSP - Add native support for JSON RPC use by LSP protocol vim/vim#9390
• diff is slow but this has been fixed by using lua as mentioned above. I have added better lua support in vim.

If you have open source repositories that has perf issues feel free to share and I can profile and figure out the bottlenecks.

[0xDagal]

As told here, it could be nice to have a DAP client, maybe in vim-lsp, maybe in another repo idk but it's sure that getting a debug adapter in pure VimScript would be really nice !

Note: why not, if it is possible, create Machine Interface for DAP so that we can use termdebug as client

[idbrii]

getting a debug adapter in pure VimScript would be really nice

You mean something like vimspector, but implemented only in vimscript? Note that vim-lsp isn't pure vimscript: some parts are written in lua for speed. But vim-lsp has vimscript fallbacks so it can run without requiring additional runtimes. Is that what you're after -- a more portable experience?

[prabirshrestha]

Lot of folks seems to want workspaceFolders support.

#1069

[prabirshrestha]

Initial workspace folder support at #1265

[zoumi]

I don't like coc.nvim. But for now coc.nvim return better complete items than vim-lsp.

[idbrii]

What's a specific example where coc returns better results? Can you point to a test file and a sample input line?

[mattn]

microsoft/language-server-protocol#737

Explicitly handling for diagnostics.

[mattn]

Current implementation is based on notification from servers. So it might be heavily. But I think this spec change is possible to ommit some notifications if vim-lsp send diagnostics request with file save.