GNU bug report logs -
#59001
Eglot activated in xref internal buffers
Previous Next
Full log
Message #8 received at 59001 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 2 years and 222 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.