GNU bug report logs - #62116
RFE: eglot: support window.showDocument LSP RPC

Previous Next

Full log

View this message in rfc822 format

From: Alan Donovan <adonovan <at> google.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: sebastian.poeplau <at> mailbox.org, Felician Nemeth <felician.nemeth <at> gmail.com>, 62116 <at> debbugs.gnu.org
Subject: bug#62116: RFE: eglot: support window.showDocument LSP RPC
Date: Fri, 12 May 2023 16:46:42 -0400

Thanks Joao,

I quickly tried this patch, and found two problems.

The first is that, because eglot-widening uses save-excursion, it
doesn't leave the cursor in the correct position; it merely jumps
there for a moment and then goes back to wherever it was before.
Removing the eglot-widening is an effective workaround.

The second issue is that Emacs still often gets stuck making a
recursive RPC, as previously discussed. I interrupted it using
toggle-debug-on-quit and recorded the emacs Lisp function call stack.
I've lightly tidied it to omit arguments and non-function sexprs:

  accept-process-output
  jsonrpc-request textDocument/documentSymbol
  eglot-imenu
  run-hooks(after-change-major-mode-hook)
  run-mode-hooks(go-mode-hook)
  go-mode()
  set-auto-mode-0(go-mode nil)
  set-auto-mode--apply-alist
  set-auto-mode
  normal-mode
  after-find-file
  find-file-noselect-1 foo.go
  find-file-noselect foo.go
  eglot-handle-request window/showDocument
  jsonrpc-connection-receive window/showDocument
  jsonrpc--process-filter

In short the handling of the showDocument downcall causes eglot to
find-file a new Go source file, whose go-mode hooks cause a
documentSymbol upcall to be sent to the server, which then blocks
indefinitely as it is still in the  middle of whatever active request
sent the showDocument downcall.

I hope this was helpful.

cheers
alan




On Thu, 11 May 2023 at 20:51, João Távora <joaotavora <at> gmail.com> wrote:
>
> Felician Nemeth <felician.nemeth <at> gmail.com> writes:
>
> > João Távora <joaotavora <at> gmail.com> writes:
> >
> >>> Since it advances the status quo, can this be merged?  If not, how
> >>> should we proceed?
> >>
> >> Haven't looked at it, but I'd say yes.  However, Alan Donovan
> >> has replied recently, with a recipe showcasing his particular
> >> use case.  I dont' have time to try it right now, but if you
> >> could try his recipe/use case with your solution, it would be
> >> great.
> >
> > It requires to patch and recompile gopls, which would be too much effort
> > for me, unfortunately.
>
> I've now followed Alan's recipe and played around a bit with this.
> Starting from your version, I came up with this simpler patch.
>
> I was about to push it, but let's hear your opinions first (though we
> can always push and tweak it later).
>
> João
>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.