bug#59001: Eglot activated in xref internal buffers

bug#59001: Eglot activated in xref internal buffers

[Juri Linkov]

X-Debbugs-Cc: João Távora <joaotavora@gmail.com>
X-Debbugs-Cc: Dmitry Gutov <dgutov@yandex.ru>

[A new issue spun off from bug#58839]

> Juri, this doesn't seem right. Eglot shouldn't be turning itself on in
> hidden buffers to start with: It's totally useless there.
>
> So you have to explain an Emacs -Q recipe that demonstrates how Eglot
> reached this nonsensical state. You haven't done that (or have you and i
> have missed it?).
>
> I tried project-find-regexp with Eglot-managed files with no problems, but
> I have no idea what you're doing.
>
> Also, this problem is totally off-topic here: this is about
> project-kill-buffers. Please start as new issue of you haven't already.

This issue is very hard to reproduce.  It occurs only when
*xref-temp* first sets one mode not eglot-managed, then
afterwards enables another mode that is eglot-managed
in the same internal buffer.  Maybe Dmitry could explain
what is going wrong.

> On Thu, Nov 3, 2022, 17:39 Juri Linkov <juri@linkov.net> wrote:
>> OTOH I completely support the request to make Eglot more resilient
>> to unforeseeable situations.  Currently it's so brittle, so I get a lot
>> of such errors all the time:
>>
>> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>>   file-truename(nil)
>>   eglot--path-to-uri(nil)
>>   eglot--TextDocumentIdentifier()
>>   eglot--signal-textDocument/didClose()
>>   kill-buffer(#<buffer  *xref-temp*>)
>>   xref--convert-hits(...)
>>   xref-matches-in-files("word" ...)
>>   project--find-regexp-in-files("word" ...)
>>   apply(project--find-regexp-in-files ("word" ...))
>>   xref--show-xref-buffer(...)
>>   xref--show-xrefs(...)
>>   xref-show-xrefs(...)
>>   project-find-regexp("word")
>>   funcall-interactively(project-find-regexp "word")
>>   command-execute(project-find-regexp)
>
> Here's a patch that fixes this:
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index c5870618372..5b05f84c63c 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -1792,7 +1792,9 @@ eglot--maybe-activate-editing-mode
>    (unless eglot--managed-mode
>      ;; Called when `revert-buffer-in-progress-p' is t but
>      ;; `revert-buffer-preserve-modes' is nil.
> -    (when (and buffer-file-name (eglot-current-server))
> +    (when (and buffer-file-name
> +               (not (string-match-p "\\` " (buffer-name)))
> +               (eglot-current-server))
>        (setq eglot--diagnostics nil)
>        (eglot--managed-mode)
>        (eglot--signal-textDocument/didOpen))))

bug#59001: Eglot activated in xref internal buffers

[Dmitry Gutov]

On 03.11.2022 20:43, Juri Linkov wrote:
> X-Debbugs-Cc: João Távora<joaotavora@gmail.com>
> X-Debbugs-Cc: Dmitry Gutov<dgutov@yandex.ru>
> 
> [A new issue spun off from bug#58839]
> 
>> Juri, this doesn't seem right. Eglot shouldn't be turning itself on in
>> hidden buffers to start with: It's totally useless there.
>>
>> So you have to explain an Emacs -Q recipe that demonstrates how Eglot
>> reached this nonsensical state. You haven't done that (or have you and i
>> have missed it?).
>>
>> I tried project-find-regexp with Eglot-managed files with no problems, but
>> I have no idea what you're doing.
>>
>> Also, this problem is totally off-topic here: this is about
>> project-kill-buffers. Please start as new issue of you haven't already.
> This issue is very hard to reproduce.  It occurs only when
> *xref-temp*  first sets one mode not eglot-managed, then
> afterwards enables another mode that is eglot-managed
> in the same internal buffer.  Maybe Dmitry could explain
> what is going wrong.

Sounds like Eglot, by means of some hooks, sets up some information 
about the buffer. And then it somehow doesn't get cleaned up when the 
major mode changes. Permanent locals? That's a question for Joao.

It is a temporary buffer, and we enable different major modes in it 
(through set-auto-mode), to be able to regexp-search in the inserted 
contents using syntax-sensitive specials (most often - \_< and \_>).

The reason we don't use delay-mode-hooks is in the linked bug report in 
the comments. Hopefully we will later, maybe after Emacs 29.

bug#59001: Eglot activated in Xref internal buffers

[Juri Linkov]

>> This issue is very hard to reproduce.  It occurs only when
>> *xref-temp* first sets one mode not eglot-managed, then
>> afterwards enables another mode that is eglot-managed
>> in the same internal buffer.  Maybe Dmitry could explain
>> what is going wrong.
>
> Sounds like Eglot, by means of some hooks, sets up some information about
> the buffer. And then it somehow doesn't get cleaned up when the major mode
> changes. Permanent locals? That's a question for Joao.
>
> It is a temporary buffer, and we enable different major modes in it
> (through set-auto-mode), to be able to regexp-search in the inserted
> contents using syntax-sensitive specials (most often - \_< and \_>).
>
> The reason we don't use delay-mode-hooks is in the linked bug report in the
> comments. Hopefully we will later, maybe after Emacs 29.

Thanks for reminding that it's the same as bug#39190
and https://github.com/joaotavora/eglot/pull/233

Though I still don't completely understand full details of bug#23272
why xref--collect-matches couldn't use delay-mode-hooks.

bug#59001: Eglot activated in Xref internal buffers

[Dmitry Gutov]

On 04.11.2022 09:29, Juri Linkov wrote:
> Though I still don't completely understand full details of bug#23272
> why xref--collect-matches couldn't use delay-mode-hooks.

That causes errors with major modes which use 
syntax-propertize-via-font-lock.

Not sure how prevalent it is these days (hopefully not), but apparently 
it can still happen with Auctex: 
https://lists.gnu.org/archive/html/auctex-devel/2022-03/msg00027.html