[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: |
Philip Kaludercic |
Subject: |
bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running |
Date: |
Mon, 31 Oct 2022 14:35:19 +0000 |
João Távora <joaotavora@gmail.com> writes:
> 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.
The condition can be written entirely, if we are willing to accept a
breaking change. In the case of `project-kill-buffer', this ought to be
acceptable if fewer buffers are killed.
> 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.
I have to admit that I am more and more inclined to make the list a
opt-in thing, where we explicitly mark those major modes that are tied
to a project.
> 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.
What existing hooks?
> 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.
I would be fine with this in principle, my only worry is backwards
compatibility for those who use project.el from ELPA.
> 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
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, (continued)
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running,
Philip Kaludercic <=
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/10/31
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/10/29
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/10/29
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/10/29
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/10/29