[vim/vim] A new lightweight LSP client written purely in Vim9 script. (Discussion #18636)

Daniel Viberg

unread,

Oct 26, 2025, 8:12:36 AM10/26/25

to vim/vim, Subscribed

A small project of mine where I'm implementing the LSP protocol in vim9script using only native Vim9 apis. It's still very alpha status, but I'm slowly adding new features and fixing bugs as times goes.

2025-10-26-13-08-47.png (view on web)

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Foxe Chen

unread,

Oct 27, 2025, 12:08:54 AM10/27/25

to vim/vim, Subscribed

Nice project, but naming it the same as an already existing vim9 project sounds kinda confusing however

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dviberg

unread,

Oct 27, 2025, 2:28:36 AM10/27/25

to vim/vim, Subscribed

Thanks, i have no issue renaming it if that's what the users want.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Maxim Kim

unread,

Oct 27, 2025, 3:33:55 AM10/27/25

to vim/vim, Subscribed

Do you plan to leverage vim's autocomplete with lsp source (omnifunc?) or would be implementing your own completion?

Is lsp communication over http planned (some lsp servers can only communicate over localhost:port, so I have to use netcat)?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Daniel Viberg

unread,

Oct 27, 2025, 4:38:03 AM10/27/25

to vim/vim, Subscribed

I experimented with lsp as a completefunc alongside any other predefined complete sources. It worked well for fast servers, but I had issues with completion state on slow servers. I might not have sufficient understanding, but i didn't manage to merge a existing buffer/omnifunc completion state with the slow lsp response without it affecting the stability (re-promt, flashing) of the existing pum. I've currently gone with something that works, but might look in to this again.

To my understanding vim9 api currently dont support http, i guess one could develop a proxy that could translate http to stdio. But my requirement is that its built by basic well know tools like curl, wget or jq or pure vim9script. It is currently not planned, I would need to check the effort for such proxy before leaving any plans.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Maxim Kim

unread,

Oct 27, 2025, 5:14:57 AM10/27/25

to vim/vim, Subscribed

@girishji did a great job trying to make autocomplete good enough with not so fast lsp servers. However, I agree, that some of very very slow servers might block vim's completion.

Still maybe a good use of the complete_check() might help? If not could be one of the future vim improvements.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Maxim Kim

unread,

Oct 27, 2025, 5:18:31 AM10/27/25

to vim/vim, Subscribed

We gonna be using yegappan/lsp or danielviberg/lsp, good enough for me :)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Daniel Viberg

unread,

Oct 27, 2025, 6:09:45 AM10/27/25

to vim/vim, Subscribed

I'll make a branch to test this again then.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

girish

unread,

Oct 27, 2025, 7:15:05 AM10/27/25

to vim/vim, Subscribed

Slow LSP servers shouldn’t cause issues for 'autocomplete'. There are several tuning options you can adjust to improve responsiveness. Be sure to implement complete_check()—the yegappan LSP client is a good reference for that. If you encounter problems with a specific slow LSP server, feel free to ping me and I’ll take a look.

Also, @habamax — do you think it would make sense to implement a few essential LSP features directly in C? I’m thinking mainly of autocompletion and perhaps a few other high-impact ones.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Maxim Kim

unread,

Oct 27, 2025, 7:32:27 AM10/27/25

to vim/vim, Subscribed

@girishji might make sense if it is going to boost perf, @yegappan did exactly this to back his lsp plugin.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Daniel Viberg

unread,

Oct 27, 2025, 7:37:20 AM10/27/25

to vim/vim, Subscribed

We gonna be using yegappan/lsp or danielviberg/lsp, good enough for me :).

Although, linux only makes it no go for me (use windows too).

I myself will need windows support so expect that to work soon.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Clason

unread,

Oct 27, 2025, 7:41:05 AM10/27/25

to vim/vim, Subscribed

Something that would be useful is built-in support for re-triggering completion requests when deleting characters (not part of the spec, but very annoying if its missing and you tend to fat-finger a lot ;)) Just something from my experience to keep in mind.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Daniel Viberg

unread,

Oct 27, 2025, 7:41:39 AM10/27/25

to vim/vim, Subscribed

@girishji Thanks. You probably have a good sense of high demand lsp apis. If i could add to that list:

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textEdit

Apply lsp text edits
Read lsp text edits

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Yegappan Lakshmanan

unread,

Oct 27, 2025, 10:30:17 AM10/27/25

to vim/vim, Subscribed

I also implemented the diff() function to enable LSP plugins to efficiently compute and send incremental buffer changes to the LSP server. Previously, plugins were required to manually compute the diff by saving a copy of the buffer and comparing its contents against the latest version.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Daniel Viberg

unread,

Oct 27, 2025, 10:48:13 AM10/27/25

to vim/vim, Subscribed

I also implemented the diff() function to enable LSP plugins to efficiently compute and send incremental buffer changes to the LSP server. Previously, plugins were required to manually compute the diff by saving a copy of the buffer and comparing its contents against the latest version.

I want to remember I saw that somewhere in a comment you made. I tried it: https://github.com/DanielViberg/lsp/blob/add871166be90bd531e6557f8ac25fcdcb495ae5/lib/Features/DocumentSync.vim#L103C3-L126C8
So far it seems to work well, I added some comments about this in your lsp repo. If I find time I can make a PR there too.
yegappan/lsp#550

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Yegappan Lakshmanan

unread,

Oct 27, 2025, 1:19:50 PM10/27/25

to vim/vim, Subscribed

I also implemented the diff() function to enable LSP plugins to efficiently compute and send incremental buffer changes to the LSP server. Previously, plugins were required to manually compute the diff by saving a copy of the buffer and comparing its contents against the latest version.

I want to remember I saw that somewhere in a comment you made. I tried it: https://github.com/DanielViberg/lsp/blob/add871166be90bd531e6557f8ac25fcdcb495ae5/lib/Features/DocumentSync.vim#L103C3-L126C8 So far it seems to work well, I added some comments about this in your lsp repo. If I find time I can make a PR there too. yegappan/lsp#550

Thanks. Can you update your PR? Does this work reliably across different types of buffer changes?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Daniel Viberg

unread,

Oct 27, 2025, 2:31:23 PM10/27/25

to vim/vim, Subscribed

I'll try to find time for a PR, I cant confirm that yet, my testing logic does not handle diff state management yet, but i can say that I've been using that solution for multiple servers for a week or two now and no desync has happened yet.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Mao-Yining

unread,

Feb 7, 2026, 2:53:17 AM (9 days ago) Feb 7

to vim/vim, Subscribed

do you think it would make sense to implement a few essential LSP features directly in C? I’m thinking mainly of autocompletion and perhaps a few other high-impact ones.

If you can, please consider about LSP semanticHighlight, from my experience, it is the most shortage of vim9lsp compared with other plugins (coc, nvim-lsp).

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

ubaldot

unread,

1:04 AM (8 hours ago) 1:04 AM

to vim/vim, Subscribed

Jätte fint! :)

I am glad to see vim9 being more adopted by people!

I go a bit off-topic here, but what I feel is still missing in Vim9 ecosystem is a debugging-adapter protocol (DAP) - there is only vimspector which is mostly in Python and legacy Vim - and Vim9 development tools, like linters, lsp servers, etc.