c-x c-o error

[it512]

[it512]

vim version : 9.1.125

[it512]

https://github.com/vim/vim/issues/14073

[it512]

https://github.com/vim/vim/issues/14073 https://github.com/vim/vim/pull/14074 @fatih

thank you! plz see

[bhcleek]

The win_gotoid call locations that were referenced in vim/vim#14073 as being causes is most likely a correct analysis. Specifically, this looks like a likely candidate.

However, given that they've proposed a patch and submitted a patch, you've confirmed it resolves the problem in Vim, and that this only affects Vim versions >= 9.1.0119 and less than whatever version the patch makes it into, I don't consider this high priority.

I'll look into using win_execute, but that may be more complicated than it first appears, and I'm less than enthusiastic about pursuing that course of action, as they've also indicated they that perhaps textlock checking should be added to it.

[Shane-XB-Qian]

The win_gotoid call locations that were referenced in vim/vim#14073 as being causes is most likely a correct analysis. Specifically, this looks like a likely candidate.

However, given that they've proposed a patch and submitted a patch, you've confirmed it resolves the problem in Vim, and that this only affects Vim versions >= 9.1.0119 and less than whatever version the patch makes it into, I don't consider this high priority.

I'll look into using win_execute, but that may be more complicated than it first appears, and I'm less than enthusiastic about pursuing that course of action, as they've also indicated they that perhaps textlock checking should be added to it.

i felt some kinds of bad feeling was happening there, this plugin lucky have you here, but some classic vim plugins had lost maintainer, then not sure who would tune/adjust such things for them.. :thinking:

-- shane.xb.qian

[seandewar]

The patch in question has now been included upstream as v9.1.0128.

I'll look into using win_execute, but that may be more complicated than it first appears, and I'm less than enthusiastic about pursuing that course of action, as they've also indicated they that perhaps textlock checking should be added to it.

That's mostly just me musing out loud. If there exists ways to close windows (or specifically, the "saved" curwin) during textlock from win_execute, it'd likely be better to just patch those holes out. (I've yet to find any.)

Anyway, provided that this plugin does not attempt win_gotoid to a different window during textlock, there should be no more problems (but maybe it's still possible if a LSP response comes in late, say, while the completion function is sleeping?).

[bhcleek]

i felt some kinds of bad feeling was happening there

Please be assured that there are no ill feelings here.

That's mostly just me musing out loud.

Thank you for clarifying.

[bhcleek]

There are a number of cases where the current window when the response handler is called is expected to be the window that initiated the request. Therefore, I don't think win_execute can be easily swapped in here. Vim-go could check the window id and only attempt to change the window if the window to be changed to is different. Vim-go could also potentially track state and avoid attempts to change the window when one of the conditions that requires textlock is active.

Given that the fix to return early when changing the window to the current window has already landed in Vim, and that fix handles the most common cases appropriately without putting additional burden on plugin authors, I'm closing this.

Thank you for the clear bug report, the fast turnaround in Vim, and the discussion.