[vim/vim] LSP Support in Vim Core (Discussion #19621)
mattn
Today, many text editors and IDEs support the Language Server Protocol (LSP). As you all know, LSP is a protocol that provides features such as code completion, syntax highlighting, and error detection, supporting a wide range of programming languages.
Vim will most likely still be alive ten years from now, and so will LSP. There is more than enough merit in adding LSP support to Vim's core functionality.
I would like to discuss and decide on Vim's direction now, while we have the opportunity. There are broadly two approaches:
Plan 1. Vim core implements the LSP client itself
Plan 2. Vim core implements the building blocks needed for an LSP client
The first plan needs little explanation. Having Vim core implement the LSP client directly is the most straightforward way to provide LSP support. This would allow users to take advantage of LSP features simply by using Vim.
The second plan is for Vim core to implement the building blocks needed for an LSP client. This means Vim core would provide the foundation for LSP client functionality. This would enable plugins such as vim-lsp and yegappan/lsp to build fast and stable LSP clients by leveraging core functionality.
As far as I know, the following are currently a burden for LSP clients implemented as Vim plugins:
- Obtaining text diffs
- Applying TextEdits
When obtaining text diffs in Vim script, you would typically call getbufline(1, '$'), but when the text is tens of thousands of lines long, this function call becomes costly — for example, applying semantic highlights can take several seconds. LSP clients should send only the changed portions to the server.
As for applying TextEdits, anyone who has implemented an LSP client will understand — applying TextEdits requires accurately and efficiently reflecting changes to a buffer based on specified positions and lengths, making it a complex and costly operation.
Implementing these in Vim script is extremely difficult, and performance issues are likely to arise. If we choose Plan 2, I believe we need to implement the following three building blocks in Vim core:
fname_to_uri(),fname_from_uri()- A way to obtain text diffs using
listener_add(), or agetchanges()function to get the current text diff applytextedits()to apply TextEdits to a buffer
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mattn
This is reference implementation of getting text diffs using listener_add()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
What about combined approach?
An official lsp plugin bundled with vim. With additional building blocks you mentioned in the last paragraph when and if needed.
There would be quite a few global/local settings users would need to set up and exposing/using them via core c would be quite cumbersome compared to vimscript.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
Today, many text editors and IDEs support the Language Server Protocol (LSP). As you all know, LSP is a protocol that provides features such as code completion, syntax highlighting, and error detection, supporting a wide range of programming languages.
Vim will most likely still be alive ten years from now, and so will LSP. There is more than enough merit in adding LSP support to Vim's core functionality.
I would like to discuss and decide on Vim's direction now, while we have the opportunity. There are broadly two approaches:
Plan 1. Vim core implements the LSP client itself
Plan 2. Vim core implements the building blocks needed for an LSP clientThe first plan needs little explanation. Having Vim core implement the LSP client directly is the most straightforward way to provide LSP support. This would allow users to take advantage of LSP features simply by using Vim.
The second plan is for Vim core to implement the building blocks needed for an LSP client. This means Vim core would provide the foundation for LSP client functionality. This would enable plugins such as vim-lsp and yegappan/lsp to build fast and stable LSP clients by leveraging core functionality.
As far as I know, the following are currently a burden for LSP clients implemented as Vim plugins:
- Obtaining text diffs
- Applying TextEdits
When obtaining text diffs in Vim script, you would typically call
getbufline(1, '$'), but when the text is tens of thousands of lines long, this function call becomes costly — for example, applying semantic highlights can take several seconds. LSP clients should send only the changed portions to the server.As for applying TextEdits, anyone who has implemented an LSP client will understand — applying TextEdits requires accurately and efficiently reflecting changes to a buffer based on specified positions and lengths, making it a complex and costly operation.
Implementing these in Vim script is extremely difficult, and performance issues are likely to arise. If we choose Plan 2, I believe we need to implement the following three building blocks in Vim core:
fname_to_uri(),fname_from_uri()- A way to obtain text diffs using
listener_add(), or agetchanges()function to get the current text diffapplytextedits()to apply TextEdits to a buffer
vim-dev ML
On Mon, Mar 9, 2026 at 5:15 PM mattn ***@***.***> wrote:
> Today, many text editors and IDEs support the Language Server Protocol
> (LSP). As you all know, LSP is a protocol that provides features such as
> code completion, syntax highlighting, and error detection, supporting a
> wide range of programming languages.
>
> Vim will most likely still be alive ten years from now, and so will LSP.
> There is more than enough merit in adding LSP support to Vim's core
> functionality.
>
> I would like to discuss and decide on Vim's direction now, while we have
> the opportunity. There are broadly two approaches:
>
> *Plan 2.* Vim core implements the building blocks needed for an LSP client
> The first plan needs little explanation. Having Vim core implement the LSP
> client directly is the most straightforward way to provide LSP support.
> This would allow users to take advantage of LSP features simply by using
> Vim.
>
> The second plan is for Vim core to implement the building blocks needed
> for an LSP client. This means Vim core would provide the foundation for LSP
> client functionality. This would enable plugins such as vim-lsp and
> yegappan/lsp to build fast and stable LSP clients by leveraging core
> functionality.
>
plugins to be developed.
> implemented as Vim plugins:
>
> - Applying TextEdits
>
The enhancements to the listener functionality in Vim 9.2 are supposed to
simplify the method to get the
changes. I haven't tried it out yet as I want the LSP plugin to work with
Vim 9.0.
I also added the diff() function to simplify getting the diff between a
cached version of a buffer and the
latest version.
>
>
> '$'), but when the text is tens of thousands of lines long, this function
> call becomes costly — for example, applying semantic highlights can take
> several seconds. LSP clients should send only the changed portions to the
> server.
>
> As for applying TextEdits, anyone who has implemented an LSP client will
> understand — applying TextEdits requires accurately and efficiently
> reflecting changes to a buffer based on specified positions and lengths,
> making it a complex and costly operation.
>
> Implementing these in Vim script is extremely difficult, and performance
> issues are likely to arise. If we choose Plan 2, I believe we need to
> implement the following three building blocks in Vim core:
>
> - A way to obtain text diffs using listener_add(), or a getchanges()
>
> We also need functions to better handle snippets with multiple variables.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
Vim channel interface.
While the Language Server Protocol specification allows for both
numeric and string identifiers
in JSON-RPC messages, the Vim channel interface currently only
supports numeric ones.
Regards,
Yegappan
vim-dev ML
>
> Hi,
>
>>
>> Today, many text editors and IDEs support the Language Server Protocol (LSP). As you all know, LSP is a protocol that provides features such as code completion, syntax highlighting, and error detection, supporting a wide range of programming languages.
>>
>> Vim will most likely still be alive ten years from now, and so will LSP. There is more than enough merit in adding LSP support to Vim's core functionality.
>>
>> I would like to discuss and decide on Vim's direction now, while we have the opportunity. There are broadly two approaches:
>>
>> Plan 1. Vim core implements the LSP client itself
>> Plan 2. Vim core implements the building blocks needed for an LSP client
>>
>> The first plan needs little explanation. Having Vim core implement the LSP client directly is the most straightforward way to provide LSP support. This would allow users to take advantage of LSP features simply by using Vim.
>>
>> The second plan is for Vim core to implement the building blocks needed for an LSP client. This means Vim core would provide the foundation for LSP client functionality. This would enable plugins such as vim-lsp and yegappan/lsp to build fast and stable LSP clients by leveraging core functionality.
>
>
>
>>
>>
>> Obtaining text diffs
>> Applying TextEdits
>
>
> changes. I haven't tried it out yet as I want the LSP plugin to work with Vim 9.0.
>
> I also added the diff() function to simplify getting the diff between a cached version of a buffer and the
> latest version.
>
>>
>>
>> As for applying TextEdits, anyone who has implemented an LSP client will understand — applying TextEdits requires accurately and efficiently reflecting changes to a buffer based on specified positions and lengths, making it a complex and costly operation.
>>
>> Implementing these in Vim script is extremely difficult, and performance issues are likely to arise. If we choose Plan 2, I believe we need to implement the following three building blocks in Vim core:
>>
>> fname_to_uri(), fname_from_uri()
>> A way to obtain text diffs using listener_add(), or a getchanges() function to get the current text diff
>> applytextedits() to apply TextEdits to a buffer
>>
>>
>
Another feature we need is support for string identifiers within the
Vim channel interface.
While the Language Server Protocol specification allows for both
numeric and string identifiers
in JSON-RPC messages, the Vim channel interface currently only
supports numeric ones.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
That would be that one here: #19003 I guess
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
mattn
In your opinion, should Vim implement an LSP client rather than being a component for LSP clients?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Maxim Kim
A C based LSP client built-in to vim?
It would be good to have. Is it feasible given the fact several independent plugins are available and the burden it would add for the maintainers? I don't know.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
mattn
Thank you. We're currently in the phase of deciding which of those to pursue, so your input is very helpful.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
I think this should be implemented in Vim9script so that more people can contribute to this. I looked into implementing the LSP support in core Vim a few years ago along the lines of the existing Netbeans support. But decided against doing that as only a few people will contribute to the C based implementation.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Foxe Chen
I'm just curious, what makes implementing string identifiers non-trivial? Would it be possible to use a hash table to match LSP requests with responses?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
@64-bitman Yes. The LSP feature depends on the Vim channel feature. The channel code can be extended to support string identifiers. Someone needs to work on this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.