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

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

bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails whe


From: Dmitry Gutov
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Date: Sun, 30 Oct 2022 21:13:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

On 30.10.2022 18:39, Eli Zaretskii wrote:
Date: Sun, 30 Oct 2022 17:58:18 +0200
Cc: philipk@posteo.net, 58839@debbugs.gnu.org, manuel.uberti@inventati.org
From: Dmitry Gutov <dgutov@yandex.ru>

On 30.10.2022 08:28, Eli Zaretskii wrote:
Those are relatively safe.  Then have a buffer-local variable for
packages to opt into -- not opt out of -- your scheme.
I believe I made a similar argument with Dmitry back when project.el
was added to Emacs.  Dmitry didn't like my suggestion back then, and I
have doubts that he changed his mind.

Do you have a link to that message? Details matter.

Not anymore, sorry.  It doesn't really matter, if you are now okay
with making buffers that don't visit files by default not belong to a
project, regardless of their default-directory.

It would help remind you of the original explanation, instead of putting me on the defensive. And recall the supporting voices from the others in the same discussion. And maybe add the explanation to the docs, if it looks that non-obvious.

To reiterate: we usually want to consider VC-Dir, Diff, Dired and Compilation buffers as part of the project. Even though they are not associated with a file. Because 'C-x p b' can be handy to switch to particular one, and 'C-x p k' can clean them up (when you're "closing" the project).

People who think differently, can use project-ignore-buffer-conditions and/or use some special backend (probably defined by themselves) that overrides 'project-buffers' with a different logic.

The issue Joao is having, however, is with particular "hidden" non-file-visiting buffers (in fundamental-mode). And here the argument could be made both ways.





reply via email to

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