Subject: RE: [External] : Re: bug#78658: 30.1; [PATCH] Dired feature suggestion: dired-on-marked-files-in-all-buffers

From: Drew Adams <[email-masked]>
Date: Thu, 5 Jun 2025 21:25:13 +0000

> > +Eli, Stefan K, Andrea, and RMS, for the find* Dired buffers
> > question (variable `dired-buffers').
> 
> Sorry, I don't understand the question.  This discussion talks about
> many different issues, and it's hard for me to re-read all of it to
> glean only the parts related to that variable.  So please ask the
> specific question you have about dired-buffers, and please provide the
> necessary background information to understand why let-binding it (or
> anything else) is a bother in this case.

I did say this much in the same message, at least:

> > Maybe Eli, Stefan K., Andrea, or RMS has a suggestion.
> > The question is whether we can reasonably remove this
> > binding from the find-dired.el and find-lisp.el code:
> > 
> >   (let ((dired-buffers dired-buffers))...)
> > 
> > IOW, is there a good reason to preclude find* Dired
> > buffers from the value of `dired-buffers'?
> > 
> > The advantage of not excluding them is that when looking
> > for Dired buffers we don't need to filter the entire
> > `buffer-list'; we can just use `dired-buffers' as the
> > search space.
> > 
> > Note: `dired-buffers' are buffers with mode derived from
> > `dired-mode'.  The list is filled by `dired-advertise'
> > and reduced by `dired-unadvertise'.  It doesn't include
> > `wdired-mode' buffers, for example, because WDired uses
> > `dired-unadvertise'.

I think that makes the question clear: whether we can remove
the binding that excludes find* Dired buffers from the list,
and if not, why not (what's the value of excluding them)?

But here's some more background -

In the current enhancement request (#78658), the plan is to
add a command that gathers all of the files & dirs that are
marked in any Dired buffers, and open Dired on only those
files & dirs.

(Passing a cons as arg DIRNAME to `dired' opens Dired in the
buffer that's the car of the cons, for just the list of files
that are the cdr.)

To do that, the command needs to work with a list of all
Dired buffers.  The ability to do something with the list of
all Dired buffers is of course more general than this command
 - more uses.

When `dired-mode' is invoked it calls `dired-advertise',
which adds the Dired buffer to the value of global variable
`dired-buffers'.  A couple commands remove a buffer name from
this list, by calling `dired-unadvertise'.  In particular,
`wdired-change-to-wdired-mode' does this, because it changes
the major mode from `dired-mode' to `wdired-mode'.

The value of var `dired-buffers' is thus generally a list of
all buffers in `dired-mode'.  (This can include buffers that
have been killed, so filtering with `buffer-live-p' is also
needed.)

The only exceptions are (1) commands `find-dired' and its
derivatives such as `find-name-dired', and (2) commands
`find-lisp-dired*'.  They're exceptions because they bind
`dired-buffers' around their work (see above), so as not to
add their resulting Dired buffers to `dired-buffers'.

This means that code can't just examine `dired-buffers' to
find the set of Dired buffers (buffers advertised to be in
`dired-mode').  Instead, it needs to filter `buffer-list',
to gather the buffers with modes derived from `dired-mode'.
That's unfortunate - it's much more costly, in general.

The question is whether there's a good reason why find*
buffers, which are in `dired-mode', should be excluded from
being "advertised" as such, i.e., whether they should really
be excluded from `dired-buffers'.  And if so, why?

It was apparently a 1998 commit by Richard that added the
protective binding to `find-dired', but with no comment as
to why.

In the Emacs sources, at least, there are no other places
that exclude `dired-mode' buffers from `dired-buffers'.
And grepping for `find-dired' shows that there are no places
that rely on such exclusion for `find-dired' buffers.  Same
for `find-lisp-find-dired-internal' (which binds
`dired-buffers' for `find-lisp*').