GNU bug report logs - #78658
30.1; [PATCH] Dired feature suggestion: dired-on-marked-files-in-all-buffers

Previous Next

Full log

Message #38 received at 78658 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Phil Sainty <psainty <at> orcon.net.nz>,
 "78658 <at> debbugs.gnu.org" <78658 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#78658: 30.1; [PATCH] Dired feature suggestion:
 dired-on-marked-files-in-all-buffers
Date: Tue, 3 Jun 2025 19:49:11 +0000

> > Dired+ has long had commands that act on all marked files & dirs
> > in a Dired buffer, and all marked files & dirs in Dired buffers
> > for marked subdirs,... defined recursively.
> >
> > IOW, instead of (as in Phil's feature) checking all Dired buffers
> > for markings, such functions check only the current Dired buffer,
> > Dired buffers for its marked subdirs, and so on recursively.
> 
> It would be too tedious to mark subdirs,

I don't agree.  It's simple and practical.

You may be thinking of your use case (below), where you
apparently want (1) a Dired buffer for each descendant
directory, (2) a Dired buffer for the top-level dir,
and (3) a Dired buffer for each subdir marked in each
such buffer.

The general case is, well, more general: you want to do
something to or with some, not all, files and dirs in a
listing, so you mark them.

> so it should be sufficient
> just to check all subdir Dired buffers.  That would be useful for the
> most common case of running this command from the project root dir
> that will collect marked files from all project Dired buffers
> and show the file names relative to the project root
> where the command was run.

I don't think that's "the most common case", and I don't
think there is a "most common case".  It's generally useful
to do what I described.

In some ways it's similar to doing things in a single Dired
buffer with inserted descendant directories.  In other ways
it's different.  Both (inserted dirs and separate buffers)
are useful.

Inserting all subdirs is rare - there's no "most common case"
of inserting all subdirs.  That use case isn't "sufficient".  

And the same holds for when you use multiple Dired buffers
instead (or in addition!).

> > Applying `dired' to that collection of marked files & dirs is
> > only one possible action.  In general, all of the usual actions
> > for marked files are provided (by separate commands).
> 
> When all marked files are collected in one virtual Dired buffer,
> then it's easy to perform all other possible actions from this buffer.

That's the "insertion" approach, applied thoroughly.  It's
long been available: just one big Dired buffer, containing
listings of all descendant directories.  When was the last
time you actually used such a listing?

> > And it would be good to let users optionally name the resulting buffer:
> > (defun diredp-marked-files-in-all-buffers (&optional buffer-name)
> >   "Dired the files and directories marked in any Dired buffers.
> > Like `diredp-marked-files', but for all Dired buffers.
> > With a prefix argument you're prompted for the name of the resulting
> > Dired buffer.  Otherwise, the name is `MARKED-ANYWHERE'."

The name I'm using now is `diredp-marked-in-any-buffers'.
I dropped the "files" part, in keeping with other Dired+
command names.

(And because it's really file and/or dir names that are
marked.  And actually it's _lines_ of a listing that are
marked -- not files, not files & dirs, not file & dir
names -- just lines.)

I have other `diredp-marked-*' commands.  E.g., `diredp-marked'
opens Dired on the marked files and directories.

`diredp-marked-recursive' is similar, but it opens Dired on
marked files & dirs, plus those marked in Dired buffers for
any marked subdirs, etc., defined recursively.

There are lots of other commands that act on marked files &
dirs, defined recursively or not, in ways other than opening
Dired on them.

> This is quite an ugly name, but the name pattern could be defined
> by a new variable with a value like "*Dired Marked %s*" where %s
> is replaced with the default directory.

Whatever.  `default-directory' is shown in the top-level
directory header line.  And it's available via `C-h v'.
I don't see that putting it in the buffer name is useful.

More likely, a user will want a buffer name that's specific
to some given context or purpose: what the buffer is _for_ --
a given project, a particular kind of markings (e.g. file types,
dates), or whatever.  The default directory isn't so important,
generally.

The default buffer name should be a simple placeholder that
says what the buffer is about in a _general_ way.  In general,
this is about files & dirs gathered because they were marked
in some Dired buffers.

Note that it's about some set of markings that existed when
the new Dired buffer was created.  Those markings need not
continue to exist.  And yet the MARKED-ANYWHERE Dired buffer
can continue to exist.  It can even be bookmarked (persisted)
and restored later.

And such a set of files & dirs need not even have a common
ancestor directory.  A file system can be a forest, not a tree.
That's the case for MS Windows, for example: two drives don't
have any parent.  The code works fine for such cases; entries
that don't have a common ancestor are listed with absolute names.

The Dired buffer created from marked files from different trees
(e.g. different Windows drives) has a `default-directory', yes,
but it isn't relevant to all of the listed files, in the same
way that it would be relevant in a "normal" Dired buffer.

E.g., here's a MARKED-ANYWHERE <toto> buffer:

 c:/usr/toto:
 d:/usr/toto/bbbbb/31 octobre 2022 Paris.zip
 d:/usr/toto/bbbbb/aaaa-YYY
 bbbbb/aaaa-YYY

The default directory is shown in the directory header line:
c:/usr/toto:.  The 2nd and 3rd files listed have the same
name and the same parent-directory name, but they're on
different drives.  The 3rd file is listed with a name relative
to the default directory.  The 1st and 2nd files are listed
with absolute names.  They have no relation to the default
directory or even to its drive; they're on the D drive, not
the C drive. 

Dired buffers from a cons DIRNAME are somewhat strange critters.
They're essentially "snapshot" listings.  In some cases it can
make sense when reverting them to reflect the current state of
the file system (e.g., removing entries for files that have
been deleted).  I do that, for example, for a snapshot-listing
command `diredp-dired-recent-files'.

In other cases it makes little or sense to do that, and what
you want really is a snapshot listing of some former state.
Reverting the buffer just relists (replays) the recorded
file names, as is.  This is the case we're talking about now,
MARKED-ANYWHERE buffers.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.