GNU bug report logs - #59001
Eglot activated in xref internal buffers

Previous Next

To reply to this bug, email your comments to 59001 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Eglot activated in xref internal buffers
Date: Thu, 03 Nov 2022 20:43:31 +0200

X-Debbugs-Cc: João Távora <joaotavora <at> gmail.com>
X-Debbugs-Cc: Dmitry Gutov <dgutov <at> 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 <at> 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))))

Message #8 received at 59001 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, 59001 <at> debbugs.gnu.org
Subject: Re: bug#59001: Eglot activated in xref internal buffers
Date: Fri, 4 Nov 2022 02:50:19 +0200

On 03.11.2022 20:43, Juri Linkov wrote:
> X-Debbugs-Cc: João Távora<joaotavora <at> gmail.com>
> X-Debbugs-Cc: Dmitry Gutov<dgutov <at> 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.

Message #11 received at 59001 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 59001 <at> debbugs.gnu.org
Subject: Re: bug#59001: Eglot activated in Xref internal buffers
Date: Fri, 04 Nov 2022 09:29:49 +0200

>> 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.

Message #14 received at 59001 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 59001 <at> debbugs.gnu.org
Subject: Re: bug#59001: Eglot activated in Xref internal buffers
Date: Fri, 4 Nov 2022 12:52:44 +0200

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

Previous Next

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