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
x/tools/gopls: occasional bogus syntax errors when editing large files in emacs via 'eglot' #41866
Comments
(CC @joaotavora in case the problem turns out to be in |
Thanks.
These bugs aren't unheard of, but they aren't easy to track down. Normally when a problem does happen on Eglot's side, it's always been reproducible with a small file. Crucially, when analyzing these bugs, it helps to have a clear picture, not only of the communication log, but of the actual human actions (or at least editing actions) that you undertook in reaching the erroneous state. |
Is it possible to get a |
The emacs-side logs are very strange. Is it expected that it would send an insertion character by character in a single notification? And then thrash around adding and removing text from the same place, again in a single notification? |
It's not optimal, but not unexpected. The real question is, of course, is it somehow outside the protocol? If so, can you point to it? This particular client speaks to many different servers which would seem not to have any problems with this format. Of course, you can probably say that about gopls any many other clients (or is everyone using VSCode these codes?) |
That said, as I've explained to @bcmills, I'd need a more objective description of the observations. "random bogus errors" don't help much. There are two bouts of editing action there. Can we have the file state before/after? Do the errors happen after any specific action? |
I unfortunately don't have the complete file state for this particular occurrence, but I can try to get a cleaner snapshot now that I know to look for it. It looks like I can also enable (add-to-list 'eglot-server-programs '(go-mode . ("gopls" "-rpc.trace" "-logfile=/usr/local/google/home/bcmills/tmp/gopls.log"))) |
I just got a repro of this by executing Curiously, the comment was already wrapped to 80 colums, so the operation should have been a no-op. File contents:
|
You probably mean |
@joaotavora, looks like this is exactly joaotavora/eglot#367! |
And I see that it is reported for |
Right. If you can confirm it only happens in that particular situation and not any other, then this bug should probably be closed. |
I don't recall any specific occurrences outside of |
Duplicate of joaotavora/eglot#367 |
What version are you using (
go version
)?With GNU Emacs 27.1 and
eglot
20200830.1254
.Does this issue reproduce with the latest release?
Yes.
What did you do?
Edited a large file (
$GOROOT/src/cmd/go/internal/modget/get.go
).What did you expect to see?
Editor window consistently displaying up-to-date diagnostics.
What did you see instead?
Occasional bogus syntax errors for lines of the program, which persist until I run
M-x eglot-reconnect
or otherwise edit away the relevant portion of the file.The bogus syntax errors seem to reflect
gopls
somehow having an inaccurate picture of the file state. (I'm not entirely sure whether the bug is due to erroneousdidChange
notifications ineglot
or due to races or bugs ingopls
. This bug reproduces frequently when editing large files but is difficult to provoke in a small standalone reproducer.)The text was updated successfully, but these errors were encountered: