From: Dmitry Gutov <dgutov@yandex.ru>
To: Stephen Leake <stephen_leake@stephe-leake.org>
Cc: Philip Kaludercic <philipk@posteo.net>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel@gnu.org
Subject: Re: [PATCH] Speed up project-kill-buffers
Date: Mon, 9 Aug 2021 06:01:54 +0300 [thread overview]
Message-ID: <0335f070-7d3b-3ed5-703a-f0a8aaae2624@yandex.ru> (raw)
In-Reply-To: <868s3whzyh.fsf@stephe-leake.org>
Hi Stephen,
I've posted a patch to
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49264#38 which should add
the necessary flexibility, for your project backend to be able to list
its buffers without being tied to the root dir.
So far it just adds a generic called 'project-buffers'.
On 30.05.2021 20:51, Stephen Leake wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>> I'm fairly sure you don't want to close the buffers visiting the
>> dependencies.
>
> Sometimes I do; I'm done working on ada-mode, and I transition to
> working on my music database, closing all ada-mode related files. Other
> times I don't; I found a bug in ada-mode, so I move to the wisitoken
> library to run tests there, closing only the higher-level ada-mode
> files.
>
> The point is that it is up to the user, to decide on a case by case
> basis.
If the distinction is indeed useful, maybe the change mentioned above
can be followed with generic 'project-externals-buffers'.
Either way, it seems you might prefer a new command like
'project-kill-other-buffers' (as opposed to 'project-kill-buffers'),
which would kill all buffers (which satisfy
project-kill-buffer-conditions, of course) that don't belong to the
current project.
>> Or if we do, that would be a globally acting modifier, and that piece
>> of logic which we would add to project-kill-buffers would just see
>> whether the buffer's default-directory is inside any of the "external
>> roots", as defined by the backend. Would that work for you?
>
> I don't follow. What is the UI? How does the information given by the
> user get passed to the backend? Only the backend can interpret
> "dependencies".
Yeah, scratch that.
>> I'd rather we try to be more strict with semantics, if possible, and
>> 'project-contains?' would only return t for buffers "inside" the
>> project, not stuff that's outside but related to it (like external
>> libraries, system includes, etc, which is what I'd like "external
>> roots" to be targeted at).
>
> Then you need an "include-external-roots" arg to project-contains, since
> sometimes that's what the user wants.
For now it's project-buffers and (potentially)
project-externals-buffers, for nicer naming and being able to implement
in the vc backend in a performant fashion more easily (having predicate
methods would require caching some information in the project instance
between the calls).
But project-contains-buffer-p and project-externals-contain-buffer-p are
still on the table, if anybody feels strongly about that choice.
>> If you want this change to happen, could you outline the cases when
>> you would and would not use this capability? Personally, I'd probably
>> never kill those buffers.
>
> I gave examples above. In general, if I'm switching to a project that
> shares some files with the current one, I don't want to delete those
> buffers. So the correct semantics would be "switching from project A to
> project B; close all non-shared buffers".
Sounds like 'project-kill-other-buffers' I described above. You might
not even need to make a distinction between project contents and
"externals" for this scenario (having 'project-buffers' return all
pertinent buffers).
But there can be other scenarios, I guess.
next prev parent reply other threads:[~2021-08-09 3:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-03 9:43 [PATCH] Speed up project-kill-buffers Philip Kaludercic
2021-05-03 12:46 ` Stefan Monnier
2021-05-03 13:06 ` Philip Kaludercic
2021-05-03 13:24 ` Stefan Monnier
2021-05-03 17:25 ` Philip Kaludercic
2021-05-03 21:12 ` Dmitry Gutov
2021-05-08 12:03 ` Stephen Leake
2021-05-08 12:30 ` Philip Kaludercic
2021-05-08 13:05 ` Philip Kaludercic
2021-05-08 17:01 ` Dmitry Gutov
2021-05-08 17:10 ` Dmitry Gutov
2021-05-16 20:36 ` Stephen Leake
2021-05-16 21:58 ` Dmitry Gutov
2021-05-19 23:37 ` Stephen Leake
2021-05-20 12:16 ` Stephen Leake
2021-05-25 1:30 ` Dmitry Gutov
2021-05-30 17:19 ` Stephen Leake
2021-05-25 1:24 ` Dmitry Gutov
2021-05-30 17:51 ` Stephen Leake
2021-08-09 3:01 ` Dmitry Gutov [this message]
2021-05-03 21:43 ` Dmitry Gutov
2021-05-03 22:45 ` Stefan Monnier
2021-05-03 22:46 ` Dmitry Gutov
2021-05-04 6:25 ` tomas
2021-05-04 10:40 ` Dmitry Gutov
2021-05-04 11:26 ` tomas
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0335f070-7d3b-3ed5-703a-f0a8aaae2624@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=philipk@posteo.net \
--cc=stephen_leake@stephe-leake.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).