bug#7126: 24.0.50; `dired-goto-file' fails when `dired' is passed a cons with absolute file names

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

emacs -Q
 
M-: (dired '("AAAAA" "c:/foo.c" "c:/bar.c"))
 
This opens a Dired buffer named `AAAAA' with the same
`default-directory' as before the `M-:'.  The Dired buffer has two
explicit entries, the files listed in the cons arg.  These are absolute
file names.
 
This is a normal, advertised behavior of `dired': you can pass it a cons
arg to have Dired list only explicit files.  And the file names can be
either relative or absolute.  It works for remote files as well as local
ones.  Generally, it works quite well.  There have been some oversights
in the code in the past, but most have now been fixed.
 
Now try `j c:/foo.c'.  (`j' is `dired-goto-file'.)  It fails.
 
The reason it fails is that `dired-goto-file' looks only for the
relative file name (e.g. `foo.c') with a space prepended.  This is so
even when you give it an absolute file name, such as `c:/foo.c'.
 
This is important not just for interactive use but because
`dired-goto-file' is a fundamental function.  It is used all over the
place in the Dired code.  This bug therefore breaks lots of things.  It
makes it impossible for 3rd-party developers to really take advantage of
the Dired feature of listing arbitrary files and directories.
 
Dired functions should make no assumptions about the listed file and
directory names.  In particular, it should not assume that the files and
dirs are in particular parent directories or that they are relative
names.
 
If a file name is absolute, then it must be respected.  If it is
relative, then it needs to be interpreted relative to the (sub)directory
heading that precedes it (as usual).
 

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-09-20 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'