From: Dmitry Gutov <dgutov@yandex.ru>
To: "João Távora" <joaotavora@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
58839@debbugs.gnu.org, manuel.uberti@inventati.org,
philipk@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 19:24:02 +0200 [thread overview]
Message-ID: <787a4362-7ff5-7dbb-9118-16e4bee5f328@yandex.ru> (raw)
In-Reply-To: <87v8o0uxn5.fsf@gmail.com>
On 31.10.2022 11:53, João Távora wrote:
> Dmitry Gutov <dgutov@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.
What have you tried?
This should take care of the specific complaint about unknown
"invisible" buffers:
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac278edd40..1e7573c740 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1223,7 +1223,9 @@ project-display-buffer-other-frame
(defcustom project-kill-buffer-conditions
'(buffer-file-name ; All file-visiting buffers are included.
;; Most of the temp buffers in the background:
- (major-mode . fundamental-mode)
+ (and
+ (major-mode . fundamental-mode)
+ (not "\\` "))
;; non-text buffer such as xref, occur, vc, log, ...
(and (derived-mode . special-mode)
(not (major-mode . help-mode)))
> 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.
Yours is the first instance so far.
> 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.
Of course it is targeted: we want ibuffer buffers to be killed just as
well when killing a project. And sly-scratch, and etc.
> 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.
This is the point where I'd normally blacklist you again.
> 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.
They are not much better than the "patch" I showed for Eglot,
correctness-wise.
And mine would make it safe against any kill-buffer calls, including
ones issued by the user.
next prev parent reply other threads:[~2022-10-31 17:24 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 12:56 bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Philip Kaludercic
2022-10-28 17:17 ` bug#58839: [Patch] " João Távora
2022-10-28 17:28 ` Philip Kaludercic
2022-10-28 17:36 ` João Távora
2022-10-28 18:14 ` Dmitry Gutov
2022-10-28 18:20 ` Philip Kaludercic
2022-10-28 18:30 ` João Távora
2022-10-28 18:40 ` Dmitry Gutov
2022-10-29 0:15 ` João Távora
2022-10-29 1:09 ` Dmitry Gutov
2022-10-29 1:39 ` João Távora
2022-10-29 11:27 ` Dmitry Gutov
2022-10-29 12:16 ` João Távora
2022-10-29 14:32 ` Philip Kaludercic
2022-10-29 20:38 ` João Távora
2022-10-29 22:01 ` Philip Kaludercic
2022-10-29 22:49 ` João Távora
2022-10-30 6:28 ` Eli Zaretskii
2022-10-30 12:40 ` João Távora
2022-10-30 15:58 ` Dmitry Gutov
2022-10-30 16:39 ` Eli Zaretskii
2022-10-30 19:13 ` Dmitry Gutov
2022-10-30 19:54 ` Eli Zaretskii
2022-10-30 21:15 ` Dmitry Gutov
2022-10-31 9:53 ` João Távora
2022-10-31 11:56 ` João Távora
2022-10-31 17:11 ` Dmitry Gutov
2022-10-31 20:36 ` João Távora
2022-10-31 22:26 ` Dmitry Gutov
2022-10-31 22:51 ` João Távora
2022-10-31 14:35 ` Philip Kaludercic
2022-10-31 17:33 ` Dmitry Gutov
2022-10-31 23:19 ` João Távora
2022-11-01 10:51 ` Philip Kaludercic
2022-11-01 13:22 ` Dmitry Gutov
2022-11-01 13:39 ` João Távora
2022-10-31 17:24 ` Dmitry Gutov [this message]
2022-10-31 20:58 ` João Távora
2022-10-31 22:51 ` Dmitry Gutov
2022-11-01 10:48 ` Philip Kaludercic
2022-11-01 10:59 ` João Távora
2022-11-01 11:23 ` Dmitry Gutov
2022-11-01 11:39 ` João Távora
2022-11-01 15:27 ` Dmitry Gutov
2022-11-01 16:23 ` João Távora
2022-11-01 22:24 ` Dmitry Gutov
2022-11-02 7:40 ` João Távora
2022-11-01 11:27 ` Philip Kaludercic
2022-11-01 11:59 ` João Távora
2022-11-01 13:03 ` Philip Kaludercic
2022-11-01 13:37 ` João Távora
2022-11-01 14:00 ` Philip Kaludercic
2022-11-01 14:11 ` João Távora
2022-11-01 14:36 ` Philip Kaludercic
2022-11-02 7:19 ` João Távora
2022-11-02 7:29 ` Philip Kaludercic
2022-11-02 7:48 ` João Távora
2022-11-02 8:21 ` Philip Kaludercic
2022-11-02 8:41 ` João Távora
2022-11-02 9:06 ` Philip Kaludercic
2022-11-02 9:52 ` João Távora
2022-11-02 11:31 ` Philip Kaludercic
2022-11-01 15:26 ` Dmitry Gutov
2022-11-01 18:44 ` Philip Kaludercic
2022-11-01 19:50 ` Dmitry Gutov
2022-11-01 20:10 ` Philip Kaludercic
2022-11-01 22:40 ` Dmitry Gutov
2022-11-01 11:36 ` João Távora
2022-11-01 22:23 ` Dmitry Gutov
2022-11-02 7:34 ` João Távora
2022-11-02 8:36 ` Philip Kaludercic
2022-11-02 8:50 ` João Távora
2022-11-02 9:13 ` Philip Kaludercic
2022-11-02 14:00 ` João Távora
2022-11-02 14:42 ` Philip Kaludercic
2022-11-02 17:32 ` Juri Linkov
2022-11-03 17:30 ` Juri Linkov
2022-11-03 18:19 ` João Távora
2022-11-02 18:16 ` João Távora
2022-11-04 1:13 ` Dmitry Gutov
2022-11-04 11:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-05 0:53 ` Dmitry Gutov
2022-10-29 6:38 ` Philip Kaludercic
2022-10-29 10:59 ` Dmitry Gutov
2022-10-29 11:12 ` João Távora
2022-10-29 11:05 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=787a4362-7ff5-7dbb-9118-16e4bee5f328@yandex.ru \
--to=dgutov@yandex.ru \
--cc=58839@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=joaotavora@gmail.com \
--cc=manuel.uberti@inventati.org \
--cc=philipk@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.