bug#18421: 24.4.50; Allow Dired to use unrelated dir trees?

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

I think this is a bug report or enhancment request, but if I'm mistaken
then I would like to know specifically why this is not a good idea, i.e,
what specific problems would ensue.

Currently, and for a long time now (forever?), `dired-insert-subdir' has
called `dired-insert-subdir-validate', which raises an error if the
subdir to be inserted is not in the same directory tree.

Can we remove this limitation that inserted dirs must be in the same
directory tree?

This is important in the context of a call to `dired' that passes a cons
DIRNAME argument, such as this:

(dired '("my dired buffer" "d:/Emacs-23.1" "c:/Emacs-23.2" "~/foo/bar"))

That gives you a workable Dired listing, except for this: you cannot
use `i' to insert the directories.

Normally, one way to work around the not-same-dir-tree problem is to
first `cd' to a directory that is a common ancestor of the directories
that you want to include.  That is just that: a workaround.  And it does
not work for MS Windows when different drive letters are involved: there
is no common ancestor directory.

So what happens if we comment out this line in `dired-insert-subdir':

 (dired-insert-subdir-validate dirname switches)

And we get rid of this `if' condition in `dired-insert-subdir-newpos'?

 (if (dired-tree-lessp dir new-dir)
     ;; Insert NEW-DIR after DIR
     (setq new-pos (dired-get-subdir-max elt)
           alist nil))

So the code does this unconditionally:

 (setq new-pos  (dired-get-subdir-max elt)
       alist    ())

That seems to fix the problem.  And I haven't noticed any drawbacks
so far.  Dired has a lot of code, however, and I no doubt have not
tested everything to see that nothing breaks with this fix.  And I
have not tried it with a platform other than Windows.

I'm looking for information about whether this fix is ill-advised and,
if so, just what problems it presents.  (I would then perhaps look at
those problems, to see whether they too can be easily fixed.)

If it does not seem ill-advised, then please consider this an
enhancement request.

Note: There are actually two parts to function
`dired-insert-subdir-validate':

1. Check whether `dired-in-this-tree'.  This is the part that this
   fix tries to deal with.

2. Check whether switches that make a difference to `dired-get-filename'
   are used for the subdir to insert (and are not used for the overall
   listing).

The code comments say that #2 is important for `dired-get-filename'.
I have not (yet) seen where/how removing `dired-insert-subdir-validate'
creates a problem, but if that comment is correct then removing it
should be problematic for `dired-get-filename' when a mix of switches
(e.g., no `F' + `F', no `b' + `b') is used.  (Does that problem
perhaps depend on whether `ls-lisp' is used?)

So if #2 is still needed, then instead of just removing
`dired-insert-subdir-validate' altogether perhaps we could remove
only its part #1.

FYI, this report was inspired by a Stack Overflow user question:
http://superuser.com/q/807939/250462, which seems like a reasonable
feature request.

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-08-15 on LEG570
Bzr revision: 117706 rgm@gnu.org-20140815043406-p5hbu97cbm7pulcn
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'