GNU bug report logs - #58839
29.0.50; project-kill-buffer fails when Eglot is running

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58839 <at> debbugs.gnu.org, manuel.uberti <at> inventati.org, philipk <at> posteo.net
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Date: Mon, 31 Oct 2022 09:53:50 +0000

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> Anyway, if we do decide to flip the switch, it should be through
> project-kill-buffer-conditions, so the user can make a different
> choice through customization.

project-kill-buffer-conditions doesn't work, I've tried it, it has this
fundamental-mode thing there that makes it impossible.  Supposedly it is
there to serve some purpose that no-one seems to be able to find a
argumentative basis for.

It's quite clear that _some_ non-file-visiting buffers can be considered
as belonging to a project's working set.  But it's very very easy to
come up with many that cannot be considered so.

Because "killing buffers" is a destructive operation, being greedy here
is a really bad design decision, as it catches an arbitrary number of
unsuspecting extensions off-guard, which have been using earmuffed
buffers for many years.  

All in all, it's like you're making a gun that only backfires 5% of the
time.

In the little time I've used this feature since the start of this
discussion I have discovered it backfires no small number of occasions:
Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
even *ibuffer* itself is targeted by this.

Project-kill-buffers is off. Its intention pretty useful, but its
implementation is a blunder.  The root cause is this overgreedy
project-buffers.  When "killing a project" the echo area asks me if I
want to kill a number of buffers that I didn't even know I had, because
of hidden buffers.  This cannot be logical and the only way the
"argument can be made both ways" is out of stubborness.

JSONRPC's buffers are hidden implementation details: the argument that
they are somehow under the responsibility of project.el just because it
can see them through (buffer-list) is blind tiranny.

The mini-languages invented in project-kill-buffers-conditions and
project-ignore-buffer-conditions are abominations.  If project-buffers
just been conservatively designed, we'd need nothing more than the
existing hooks for the exceptions.  *earmuffed* buffers interested in
opting in could declare if it belonged or not in one line.  Just like

diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
index dc3ed52650..718bebc7cd 100644
--- a/lisp/vc/vc-dispatcher.el
+++ b/lisp/vc/vc-dispatcher.el
@@ -179,6 +179,7 @@ vc-setup-buffer
   (let ((camefrom (current-buffer))
 	(olddir default-directory))
     (set-buffer (get-buffer-create buf))
+    (setq-local project-owned t)
     (let ((oldproc (get-buffer-process (current-buffer))))
       ;; If we wanted to wait for oldproc to finish before doing
       ;; something, we'd have used vc-eval-after.

To name one.  The above is just the converse of the solution proposed by
Philip before.

Anyway, I've now suggested and presented 2 actually tested, actually
working patches to project.el.  I don't have anything more to add.

João

Previous Next

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