-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Snippets Causing Huge Delay #340
Comments
I just tried out the server with neovim and I also experience the lags. I will investigate further, but I don't see the same behaviour for VSCode, so this is potentially an issue of sorts with neovim. |
Maybe it's not related but I noticed the lag too and after a bit of digging I found out that on my pc vhdl_ls is not killed after closing neovim. So after two weeks I had around 200 instances of vhdl_ls running and killing all of them mostly solved the lag. |
I have also noticed this before. Not sure if it's related. I just killed all orphaned processes, then tested, still getting the same lag. |
yeah, I was talking with a coworker who uses VSCode, and he doesn't have the issue. I assumed this was a neovim specific problem, since VSCode is the "default" most people use. So if it were affecting that as well, this probably would have come up way earlier. I tried a different completion engine, |
This is only temporary. I am using nvim-cmp for _everything_ besides completions in VHDL buffers, since nvim-cmp freezes the whole editor when unisim is loaded and snippets are enabled. However, who knows, I may switch to coq_nvim completely if I can config it as nicely as nvim-cmp is See: hrsh7th/nvim-cmp#2028 VHDL-LS/rust_hdl#340
This is only temporary. I am using nvim-cmp for _everything_ besides completions in VHDL buffers, since nvim-cmp freezes the whole editor when unisim is loaded and snippets are enabled. However, who knows, I may switch to coq_nvim completely if I can config it as nicely as nvim-cmp is See: hrsh7th/nvim-cmp#2028 VHDL-LS/rust_hdl#340
I love that github showed the reference to my dotfiles repo commits.... |
I would like to kindly ask if this issue is still occuring. |
I just updated all of my nvim plugins, and I don't think it is happening. However I am noticing a lot of lag with the LSP in general, I have noticed that before occasionally. I think this is causing a long delay in the snippets being completed, but it is no longer freezing my entire editor. So that's a plus I guess? |
Not sure if this is a great title, so I can change it if necessary. I have been having an issue recently, where I have huge delays when my editor (Neovim) goes to complete something. I boiled it down to when the client says that snippets are supported or not (with the
capabilities.textDocument.completion.completionItem.snippetSupport
flag). I have further boiled it down to when there is a library in the scope that has a lot of possible entities that can be completed. The reason I am hitting this is because of Xilinx'sunisim
library, which houses the VHDL component declarations for all of their primitive elements. In this file, there are a whopping425
components defined. When this is included in the project and included in the unit I am working in withlibrary
/use
calls, I am experiencing 1-5s of delay when completing an item. During this delay, my entire editor freezes.I am not sure if this is an issue specifically with
vhdl_ls
, Neovim'snvim-lspconfig
(doubt), or the completion engine I am using,nvim-cmp-lsp
(potentially? relevant reddit post, but that says that it is probably the LSP server).Obviously there are a couple ways to work around this issue
unisim
library from the project. This is also not ideal, since then it can't lint these instantiations, and gives a ton of errors if you use them.Since neither of these are great, would it be possible to add another work around by adding the ability to disable snippets on a library by library basis? Something like
This might also be a symptom of another, deeper issue that can be solved. Since it would be nice to have the instantiation snippets for the primitives that are defined here (although IMO not necessary. Most of the time I am not using these primitives, and if I am, I will probably copy the template out of Xilinx's docs).
The text was updated successfully, but these errors were encountered: