bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59001: Eglot activated in xref internal buffers


From: Dmitry Gutov
Subject: bug#59001: Eglot activated in xref internal buffers
Date: Fri, 4 Nov 2022 02:50:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]