bug#70593: 30.0.50; Dired: buffers of renamed dirs are broken

[Drew Adams]

> I'm CC'ing Drew.  Drew, do you happen to have any experience with this
> case case (in general)?

Thanks for cc'ing me.

No, I have no particular experience with the
`dired-rename-subdir' code, other than using it in
typical ways.

In general, the support for a cons value of
`dired-directory' is not 100% wonderful.  I'm not
surprised when some uses of `dired-directory' don't
really handle the cons case or don't handle it well.

IMO the cons case is an important Dired feature,
but it's not taken into account well everywhere.

This is maybe partly the result of it being ignored
when changes have been made over the years to some
of the underlying basic functions.  IOW, use of a
cons `dired-directory' might not get tested after
some basic-level code change.

A Dired listing of arbitrary files (the cons case)
can be complicated, especially when it comes to
reverting the listing and in the face of changes
such as renamings.  Some of the basic plumbing
functions can be involved, and that's where some
of the complication lies.

Dunno whether it helps or would waste your time,
but in dired+.el I redefined some if the basic
functions to support a cons `dired-directory'.
E.g., you might look at `dired-buffers-for-dir'.
This is the comment for it in dired+.el:

;; REPLACE ORIGINAL in `dired.el'.
;;
;; 1. Allow for consp `dired-directory' too.
;; 2. Updated for Emacs 28: Added optional arg SUBDIRS-P.
;; 3. Fix for Emacs bug #52395.  Expand DIR with
;;    `default-directory', so `file-name-as-directory'
;;    gets applied to absolute name.  Otherwise,
;;    (dired-buffers-for-dir "~/some/dir/") returns nil,
;;    because the element in `dired-subdir-alist' is
;;    ("/the/home/dir/some/dir/" . #<buffer dir>), not
;;    ("~/some/dir/" . #<buffer dir>).

> In the meantime I've though about this particular question:
> 
> > (1) What do we need to do we do when `dired-directory' is a cons
> > (i.e. dir along with a file list)?  The existing code just threw away
> > the file list (that's why I unified the cases for now - the code didn't
> > make sense to me).

`dired-directory' is a buffer-local variable.
I don't think there's any support for subdir
listings that are of arbitrary files (i.e., cons
`dired-directory').  I don't recall, but I think
that's the case - in which case it shouldn't
matter that such a list of arbitrary files is
discarded here.  But it should be checked first.
And maybe there's a need for an error message
somewhere if things aren't as expected (?).

However, the explicit list of files can of course
include (arbitrary) directory names.  And in the
Dired buffer you can use `i' to insert a "subdir"
listing (which really means you can insert a
listing of any of the directories that are listed).

If you do that to insert a directory that's one of
the arbitrary files listed in `dired-directory',
then the files and dirs listed in that inserted
directory listing are not included in the
`dired-directory' cons value - it defines only the
main listing, not any inserted "subdir" listings.

So I think there's no problem with discarding the
explicit list of files in the case you raise.  But
I don't really know.

> I continue thinking like that.  But what should we do instead?  The file
> list can contain anything - relative or absolute names. 

Yes, the top-level listing (i.e., the value of
`dired-directory') can.

> And there can
> be names affected by the renaming operation in the list even when the
> `dired-directory' is not affected.  Would we want to exchange affected
> file names in the list silently, or leave them as they are?

Not sure I follow completely, but I think yes,
rename them in `dired-directory' also.  Maybe
if you showed some examples it would be clearer.

HTH somehow, though I doubt it.

Overall, I'd say that it's good to at least try
to test a bit with the cons `dired-directory'
case, whatever changes/fixes you might make.