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

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: sebastian.poeplau <at> mailbox.org, adonovan <at> google.com, 62116 <at> debbugs.gnu.org
Subject: bug#62116: RFE: eglot: support window.showDocument LSP RPC
Date: Sun, 14 May 2023 20:19:25 +0100

On Sun, May 14, 2023 at 8:02 PM Felician Nemeth
<felician.nemeth <at> gmail.com> wrote:
>
> >> Even when takeFous is nil, shouldn't we still at least raise the frame?
> >> Otherwise Emacs might not show the document.
> >
> > I don't understand.  Can you show this problem. , I think display-buffer
> > ensures the buffer is displayed.  It doesn't guarantee that it is
> > visible in the context of the windowing system, but that's another
> > matter.
>
> I was worried about the case when there are two frames: frame A is in
> focus, and frame B is minimized but contains the target buffer.  But
> you're right.  display-buffer does raise frame B and keeps the focus in
> frame A.

I hadn't thought of this, but good to know that display-buffer handles
it.

> > I pushed a version with the above adjustments to master, as we're
> > converging anyway and it's easier than trading patches.
>
> The pushed version is good, but there is one minor problematic detail.
> It returns "success" even before it tries to find-file the requested
> URI.  So if it cannot open the file, because the user does not have the
> required permissions, it is too late to send an error to the server.

Oof, you're right.  That's why I didn't want the async version.  Hmm, so
either we go back to the sync version (and solve the problems that that may
bring -- which AFAICT are only speculations about imenu/which-func at this
point) or we do some file-readable-p checking.

Though the latter isn't horrible, ideally we would just proclaim that
putting request-generating hooks into the major-mode hook isn't allowed.
Because it's a bad idea anyway, since a mode hook is supposed to be cheap.
Maybe eglot-request could error out (or warn and return nil) when it
detects it's running in the mode hook.  FWIW my new breadcrumb.el extension,
which also uses imenu, _can_ be put in the mode hook because it calls the
imenu-building, request-generating function asynchronously.  So it isn't
a problem there.

I wonder if Alan could inform us about the contents of his go-mode-hook,
to check if which-function-mode lives there.  That would dispel the
speculation.

João

Previous Next

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