Dired restrictions on arbitrary file & dir listings

[Drew Adams <drew.adams@oracle.com>]

1. Let users create arbitrary Dired listings interactively?

You can open Dired for virtually any list of files and dirs
(root directories such as c:/ and / should not be included).
Today, you cannot do this interactively, but you can do it by
passing a cons DIRNAME arg to `dired': the car is the Dired
buffer name, and the cdr is the list of files/dirs.

This feature has been present from the beginning, AFAIK, but
users are not very aware of it.

Why not let users do this interactively, by using a prefix
arg <= 0?  A prefix arg >= 0 means prompt for `ls' switches.
A non-positive arg would prompt for the buffer name and files.
(The current behavior of plain `C-u' would be preserved.)

I do this in Dired+, modifying `dired-read-dir-and-switches'.
It loops with `read-file-name' using lax completion, so you
can use glob patterns to specify multiple files/dirs at once.


2. Remove `dired-insert-subdir-validate'?  

You can use `i' to insert a subdir listing, but function
`dired-insert-subdir-validate' is a gatekeeper that prevents
you from inserting a directory in these two cases:

* it is not in the same directory tree as `default-directory'

* the `ls' switches you request for the listing to insert
  "conflict" with those for the main listing, where this means
  that switch -b or -F is present for one and absent for the
  other

This code is quite old.  I wonder whether it is really useful.
AFAICT so far, it is not.

a. The comment that takes the place of a doc string speaks of
protecting against trying to insert `..'.  But that is already
taken care of by the call to `dired-get-filename' in
`dired-insert-subdir', which raises the error for `..'.

b. Those two cases are completely unrelated.  That they
find themselves coupled in this function is a bit suspect.

c. Why not be able to insert directories that do not belong
to the same tree?  I have been doing this and have not noticed
a problem.  I reported this as bug/enhancement #18421 (no
response so far).

This feature is quite useful.  You can not only have Dired
list any files and dirs you want, but you can also use `i'
to insert any of those dirs.  Inserted dirs need not be from
the same root (e.g., on Windows, listings can be for dirs on
different drives).

d. Just what is the purported conflict between having some
listings that use some switches and other listings with
other listings, when some of them use -b or -F and others
do not?

There is no indication in the code - no comment.  And users
are not given a reason in the error message; it says only
"Can't have dirs with and without -%s switches together".

Well, why not?  Again, I've been using `dired-insert-subdir'
without `dired-insert-subdir-validate', and I have not
noticed a problem.  Granted, I use MS Windows, and `ls-lisp'
does not always have exactly the behavior of `ls'.  But I
asked a GNU/Linux user to test briefly, and he saw no
problem either.

This is not exhaustive testing.  But then again, it's not
clear what should be tested: just what is the supposed
conflict between having a mix of switches (no `F' + `F',
or no `b' + `b')?  What is `dired-insert-subdir-validate'
protecting us from?

My guess is that this code is a vestige.  Perhaps it used to
compensate for `dired-get-filename' not correctly handling
file names when -F is present in some listings but absent
from others?  Nowadays, `dired-get-filename' uses a text
property to handle name retrieval correctly, and it seems
to have no problem with a mix of F and no-F.

Perhaps one of you knows the history of this code and the
rationale behind the restrictions imposed by it?  I've so
far not seen any use for `dired-insert-subdir-validate'
(including brief testing with `wdired-mode').

Can we please relax these restrictions?  Or can someone
please provide a good reason why we should not do so?
Dired is a lot more useful if you can use it with an
arbitrary listing of files and dirs.

If someone wants to test a bit with the code I use, you
can get it here:
http://www.emacswiki.org/emacs-en/download/dired%2b.el