Open aqez opened 3 years ago
One more video also showcasing it, maybe a bit better:
Thanks for the videos, they make it very easy to see the problem.
I haven't experienced this myself I don't think. I can't tell really where the issue is yet, but let's try a couple of things.
First, does this happen in Vim too? I expect it will, but it'd be good to check.
Once we know this is vim/nvim agnostic, the debug log might be useful. Try adding this to your .vimrc:
let g:OmniSharp_loglevel = 'DEBUG'
(Note: Using loglevel 'debug' will output the full request/response JSON for all server interactions. We're not currently interested in those, so using upper-case 'DEBUG' is a hacky little feature which excludes those)
Then open your project and generate the error again.
Now your log will have a fair bit more info in it, so post that and we can see if there's anything illuminating there.
Here's the gist of the log at DEBUG level, I didn't see anything immediately obvious: https://gist.github.com/aqez/e50ef983ad19a4020a704ba37ab3a2eb
Also, it does happen in vim as well (8.1.2269)
Hmm. That log is quite different, under the latest version of the server. Could you try with the previous version and see if this is still happening there?
:OmniSharpInstall v1.37.3
You know what.. I think it has to do with timing. When I navigate slowly it does not appear to happen, but hitting ctrl-o to go back a bunch of times quickly seems to hit it every time:
This is on v1.37.3 of omnisharp.
Here's the log: https://gist.github.com/aqez/ec5755a8bf0d0b1171c1584584236110
Could it make sense that I was hitting it much more often on that new version of omnisharp because the responses are so much bigger?
Very peculiar, I've been trying to reproduce but can't.
I wonder if multiple servers might be getting launched? Not sure if that makes sense - can you check with :OmniSharpStatus
that there is only a single server listed?
Oh! I can reproduce with a clean vim environment, with your .vimrc
OK, I haven't got more time now but since I can repro, I can look into this later on
Do you use the semantic highlighting? I can't seem to get it to reproduce with the semantic highlighting turned off. When highlighting is set to 2/3 I do see the errors that are showing up in the /codecheck response after swapping buffers very quickly. Not sure why though. You probably already have a good way to do this, but I use tail -f
on the omnisharp-vim log to 'follow' the log as I move around the files, makes debugging the server calls very easy
Yes, I use the default (2
)
Got it!
set hidden
I must admit I don't yet understand exactly how the issue is occurring, and it should be possible to use OmniSharp-vim with set nohidden
, I'll look further into this at some point (don't close the issue!). But hopefully using set hidden
will be an acceptable workaround for you?
That’s very interesting and I’m honestly surprised I don’t have set hidden
! I will give this a shot next time I’m at my computer and let you know how it goes. Thanks for looking at this, you are probably my favorite GitHub contributor with how much help you’ve given me with omnisharp-vim. I hope to be able to give back more in the form of pull requests soon!
That does seem to fix it! All this time I thought I had hidden set, but apparently not! I saw that it always kept the buffers listed in :ls
but I guess that is just the metadata for opening them back up. Now I see them there with a status of hidden and it doesn't give me that error. Thanks!
I've got a video here of what exactly happens. I'll also include my .vimrc and the omnisharp-vim log. The video shows it happening in the initial file I opened, but it also opens in any other random files at any random time it seems. What other info can I give or where else can I look to find out more info about why this is happening?
Video https://youtu.be/fhkaFtw3eOg
vimrc: https://github.com/aqez/dotfiles/blob/master/.vimrc
omnisharp-vim log: https://gist.github.com/aqez/12504385944cd24371e4fd6addeb907a