Terminal completely freezes when selecting CSS completions from the LSP

[renanbrayner]

I tested this with both with Vetur, Volar and the Svelte LSP also with Alacritty and Kitty, in all cases it completely freezes the terminal, the cusor gets stuck and I need to kill the neovim process to get the terminal back. I don't know what may be causing the problem, but it seens to be specifically linked to selecting LSP completions for CSS

[renanbrayner]

I ran into this same issue again when using Lua completions, specifically variables

Just an update: it seens that it only happens when the preview window has an import on it, I'm ignorant towards how lua or coq works so I don't know if this is useful info or not, but I decided to update this comment anyway

[Doerge]

I have a similar problem, but with Elixir LSP function completions specifically. Neovim completely freezes, and I have to kill it. Everything other completion works great.

[mad-briller]

same issue with php method completions unfortunately

[ohjunseung]

Same problem here. This issue doesn't exists in 5eddd31bf8a98d1b893b0101047d0bb31ed20c49. I'm reverting to this commit for now.

After git bisect. I found this problem started on this commit c68f129646875bbf7ae57d8e69cabb64d0398450.

[LoeschMaximilian]

Same problem here. This issue doesn't exists in 5eddd31. I'm reverting to this commit for now.

After git bisect. I found this problem started on this commit c68f129.

This also fixes the same Issue with elixirls's function completion that @Doerge and myself seem to have

[copypasteonly]

Same problem can be experienced with nvim-jdtls function completion though it happens only on functions with imports.

[copypasteonly]

Same problem here. This issue doesn't exists in 5eddd31. I'm reverting to this commit for now.

After git bisect. I found this problem started on this commit c68f129.

Hello would like to ask how you reverted to that commit, I did git checkout 5eddd31 yet it said error: pathspec '5eddd31' did not match any file(s) known to git. Thank you!

Edit: I tried doing git checkout 5eddd31bf8a98d1b893b0101047d0bb31ed20c49 . it responded with fatal: reference is not a tree: 5eddd31bf8a98d1b893b0101047d0bb31ed20c49

Edit2: Fixed by doing git fetch --unshallow and doing git checkout 5eddd31bf8a98d1b893b0101047d0bb31ed20c49 .

[ohjunseung]

Edit2: Fixed by doing git fetch --unshallow and doing git checkout 5eddd31bf8a98d1b893b0101047d0bb31ed20c49 .

Yes you need to do a non shallow clone. If you use vim-plug this also do the same: Plug 'ms-jpq/coq_nvim', {'commit': '5eddd31bf8a98d1b893b0101047d0bb31ed20c49'}

[mattdonnelly]

So looks like this issue has existed since September 17 and nothing's been done to adddress in almost 3 months, even though it makes Coq basically unusable. The speed benefits of this plugin don't seem worth the lack of stability. I'll be switching to nvim-cmp for now

[frm]

Adding to this, Elixir LSP functions freeze up, but not all of them. Haven't been able to find a consistent pattern or a consistent way to reproduce this issue but it randomly freezes everything, making coq unusable.

[Sivecano]

any updates on this? is COQ just unusable? :(

[copypasteonly]

any updates on this? is COQ just unusable? :(

No updates from @ms-jpq afaik, though it is still very usable using the workaround mentioned above.

[ohjunseung]

something about this cmd function call that blocks the execution.

if isinstance((extern := new_metric.comp.extern), ExternLSP):
    await cmd(extern=extern)

coq/server/registrants/omnifunc.py:176

since this function only being used in the context above, disabling (commenting the body of) this function also works fine. coq/lsp/requests/command.py:10

[TheLeoP]

I have figured out what the problem is. As @ohjunseung said, the file coq/lsp/requests/command.py:16 is the start of the problem, it calls async_request passing lsp_command as the name parameter. Then, on the file coq/lsp/requests/request.py:94 the lua command COQ.lsp_command is called (on the file coq/lsp/requests/lsp.lua ) which sends the request with the respective LSP command to the LSP servers and then notifies the python process running coq on either coq/lsp/requests/lsp.lua:93 or coq/lsp/requests/lsp.lua:77 (I'm not sure which one is, but I'm sure it's one of them) which calls this python code coq/lsp/requests/request.py:64 that should notify the waiting python thread (coroutine? I don't really use Python).

The problem is that the lua code sometimes gets executed before the Python process starts waiting to be awaken, so it just frozes Neovim.

TLDR: a race condition between lua and Python is causing this issue. I'll try and see if I can create a PR to fix this, but since I'm not very good at Python, I would appreciatte any help :3

[TheLeoP]

I think I know what the problem is. The RPC function _comp_done (where the code highlighted by @ohjunseung is) is blocking (it gets called from Neovim using vim.rpcrequest). This isn't a problem in most cases, but when the LSP has to execute a workspace command, the code highlighted by @ohjunseung gets executed. This code calls Neovim and waits for a response on the function _lsp_notify (here is where I'm not sure about what happens, but I did my best to try and guess).

My guess is that Neovim can't respond, because it is waiting for a response from coq. And, at the same time, coq can respond because is waiting for a sync response from Neovim (await cmd(extern=extern)). This does not happen if one of the following two things changes:

a) the function _comp__done is changed to be non-blocking b) the call to cmd is changed to not be sync anymore

Since before the client rewrite, the function _comp_done was still blocking and I think that the cmd function was called in a non sync way (I dindn't check the code of the old client much), I'm lead to belive that the way to solve this change is to simply call cmd like create_task(cmd(extern=extern)) using asyncio.

I would have never thought that I could learn so much Python in so little time to make a change so small :'v.

[ohjunseung]

Great! Finally we can be done with this.

On Tue, May 2, 2023, 1:40 AM TheLeoP @.***> wrote:

I think I know what the problem is. The RPC function _comp_done (where the code highlighted by @ohjunseung https://github.com/ohjunseung is) is blocking (it gets called from Neovim using vim.rpcrequest). This isn't a problem in most cases, but when the LSP has to execute a workspace command, the code highlighted by @ohjunseung https://github.com/ohjunseung gets executed. This code calls Neovim and waits for a response on the function _lsp_notify (here is where I'm not sure about what happens, but I did my best to try and guess).

My guess is that Neovim can't respond, because it is waiting for a response from coq. And, at the same time, coq can respond because is waiting for a sync response from Neovim (await cmd(extern=extern)). This does not happen if one of the following two things changes:

a) the function _comp__done is changed to be non-blocking b) the call to cmd is changed to not be sync anymore

Since before the client rewrite, the function _comp_done was still blocking https://github.com/ms-jpq/coq_nvim/commit/c68f129646875bbf7ae57d8e69cabb64d0398450#diff-4e799011ed3d1c57374a6e4c969121e1f8497df22fe128b9db7b8292374a4d68L155 and I think that the cmd function was called in a non sync way https://github.com/ms-jpq/coq_nvim/commit/c68f129646875bbf7ae57d8e69cabb64d0398450#diff-4e799011ed3d1c57374a6e4c969121e1f8497df22fe128b9db7b8292374a4d68L210 (I dindn't check the code of the old client much), I'm lead to belive that the way to solve this change is to simply call cmd like create_task(cmd(extern=extern)) using asyncio.

I would have never thought that I could learn so much Python in so little time to make a change so small :'v.

— Reply to this email directly, view it on GitHub https://github.com/ms-jpq/coq_nvim/issues/531#issuecomment-1530058363, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMVXK5KSRGQCBRFNAQII35TXD77QBANCNFSM6AAAAAARNMMLZ4 . You are receiving this because you were mentioned.Message ID: @.***>

[Sivecano]

I think I know what the problem is. The RPC function _comp_done (where the code highlighted by @ohjunseung is) is blocking (it gets called from Neovim using vim.rpcrequest). This isn't a problem in most cases, but when the LSP has to execute a workspace command, the code highlighted by @ohjunseung gets executed. This code calls Neovim and waits for a response on the function _lsp_notify (here is where I'm not sure about what happens, but I did my best to try and guess).

My guess is that Neovim can't respond, because it is waiting for a response from coq. And, at the same time, coq can respond because is waiting for a sync response from Neovim (await cmd(extern=extern)). This does not happen if one of the following two things changes:

a) the function _comp__done is changed to be non-blocking b) the call to cmd is changed to not be sync anymore

Since before the client rewrite, the function _comp_done was still blocking and I think that the cmd function was called in a non sync way (I dindn't check the code of the old client much), I'm lead to belive that the way to solve this change is to simply call cmd like create_task(cmd(extern=extern)) using asyncio.

I would have never thought that I could learn so much Python in so little time to make a change so small :'v.

you are a hero, thank you.

[mad-briller]

so good to see this fixed, thanks all