GNU bug report logs -
#78658
30.1; [PATCH] Dired feature suggestion: dired-on-marked-files-in-all-buffers
Previous Next
Full log
View this message in rfc822 format
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "psainty <at> orcon.net.nz" <psainty <at> orcon.net.nz>,
> "78658 <at> debbugs.gnu.org"
> <78658 <at> debbugs.gnu.org>,
> "juri <at> linkov.net" <juri <at> linkov.net>,
> "stefankangas <at> gmail.com" <stefankangas <at> gmail.com>,
> "acorallo <at> gnu.org"
> <acorallo <at> gnu.org>, "rms <at> gnu.org" <rms <at> gnu.org>
> Date: Sat, 7 Jun 2025 16:52:14 +0000
>
> > If we allow find-dired to add its buffers to the list in
> > dired-buffers, we need to make sure they are removed from the list.
> > We also need to make sure that functions which scan the list and
> > operate on its buffers will DTRT with find-dired buffers found in the
> > list. Is all of this reasonable to do, and if so, is it planned to be
> > done as part of the changes you are discussing?
>
> I'm afraid I don't understand.
>
> 1. What do you mean by making sure they're removed from the list? The only reason to remove a file/dir from the list is, as is the case with WDired, if the mode is changed from `dired-mode' to something else. (WDired removes its buffer from the list, for that reason.)
>
> As I said, there are no uses of `dired-buffers' in the Emacs source code, apart from what I mentioned - no function that accesses `dired-buffers' at all.
>
> 2. What do you mean by a function operating on Dired buffers doing the right thing? What can that possibly mean, independent from any particular such function?
>
> Again, no Emacs source code accesses (in order to operate) on its buffers.
It is accessed in dired.el, AFAICT.
What I meant is that if find-dired wants to use this variable, it
needs to play by the rules the other users do. Don't ask me about the
details, because I'm not familiar with them. But it is clear that
there's a protocol wrt this variable, which determines when and which
buffers are added to the list and when they are removed. I'm saying
that find-dired should abide by the same protocol.
As for the DTRT part, what I meant was to ask whether the current
users of dired-buffers will know what to do with buffers put there by
find-dired, or might they be surprised and confused by them? Buffers
created by find-dired are in Dired mode, but they are not exactly
Dired buffers, in the sense that they don't necessarily show files
that live in the same directory. E.g., what will happen if the user
invokes Wdired on such a buffer?
Again, please don't ask me to provide you with detailed instructions,
because I don't have them. I asked the questions that bothered me wrt
to allowing find-dired to use this variable, but the answers should
come from people who want to allow that, after they do the necessary
research into the current uses of the variable and the possible
effects of allowing find-dired add its buffers to the list.
Put it in other words: currently dired-buffers seems to be an internal
variable used by Dired for its own purposes; if find-dired wants to
become its user, it should make sure it will play by the same rules so
as not to disrupt its current users.
> I suspect that the prohibition for `find*' was overengineering, for lack of full understanding of Dired.
I rather guess that there was a real problem which caused that, but
that problem is lost to time, or at least I wasn't able to find its
description. The date of the change predates all the mailing lists we
nowadays use, including even my private archives of the private
mailing list we used back then.
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.