Have you considered using the built-in semantic tokens information instead of sending the request/parsing the replies from the plugin?
If the server supports semantic tokens and it isn't explicitly disabled, then neovim's native LSP will store information in the semantic tokens module for every token in the buffer. You can easily access any token at any position in the buffer using vim.lsp.semantic_tokens.get_at_pos() (:help get_at_pos).
There is also an LspTokenUpdate autocmd fired for every token as it's displayed in a window for the first time.
I briefly looked through the semantic token usage and it seems like it could be simplified by leveraging the already-parsed semantic token information in the native LSP module. I know that semantic token responses can be large, and parsing them can be pretty cpu intensive. A lot of care was taken in the native LSP module to keep the editor from becoming laggy. The current code here just loops through the entire response, which on some files for some LSPs, will freeze up/lag the editor, and also doesn't take the encoding into account for getting column number from the response.
Let me know if you want me to throw up a PR for this (I'm the original author of neovim's semantic token support).
Have you considered using the built-in semantic tokens information instead of sending the request/parsing the replies from the plugin?
If the server supports semantic tokens and it isn't explicitly disabled, then neovim's native LSP will store information in the semantic tokens module for every token in the buffer. You can easily access any token at any position in the buffer using
vim.lsp.semantic_tokens.get_at_pos()
(:help get_at_pos
).There is also an
LspTokenUpdate
autocmd fired for every token as it's displayed in a window for the first time.I briefly looked through the semantic token usage and it seems like it could be simplified by leveraging the already-parsed semantic token information in the native LSP module. I know that semantic token responses can be large, and parsing them can be pretty cpu intensive. A lot of care was taken in the native LSP module to keep the editor from becoming laggy. The current code here just loops through the entire response, which on some files for some LSPs, will freeze up/lag the editor, and also doesn't take the encoding into account for getting column number from the response.
Let me know if you want me to throw up a PR for this (I'm the original author of neovim's semantic token support).