bug#7617: 24.0.50; `expand-file-name': removal of slashes

[Drew Adams]

> On Unix and GNU/Linux -- always, in the sense that file-related system
> calls will treat them the same.  On Windows -- sometimes, depending on
> the implementation of the standard C library.

A last attempt to communicate, in hopes that you actually were trying to
understand but I didn't explain myself well enough.

I understand that a file system might treat ...//... the same as .../....  From
a file-system point of view, the two might well be equivalent (the file system
ignores the extra slash).

But Emacs treats ...//... in the minibuffer as a file name that is equivalent to
/... -  as far as user input is concerned, ...//... is equivalent to /....  And
as user input .../... generally targets a very different file than does ...//...
- they are not equivalent.

So the question for `expand-file-name' is what kind of file-name arguments is it
supposed to handle - what are the arguments to `expand-file-name' expected to
be?

If we say that they must be strings acceptable to the file system, then the
current behavior is correct, and the only fix needed for `expand-file-name' is
wrt the doc (mention the slash collapse and say what forms the args must take -
and what happens if they are not of the right form).

If we say that the args can be any strings that Emacs accepts as file names
during input, then the story is different, and the proper fix is the behavior I
suggested (the Emacs 20 behavior).  In that case, `expand-file-name' is more
tolerant, accepting a wider class of strings.

And in that case, the resultant canonicalization does not necessarily produce a
file name acceptable to the file system, even if it produces a name acceptable
as file-name input for Emacs.  (Just as, in the other case, canonicalization of
...//... generally makes the name target the wrong file.)

IOW, the question here is about the purpose of `expand*'.  The behavior changed
from Emacs 20 to 21, with apparently no record of why.

My code that DTRT in Emacs 20 breaks with later versions because of this change,
so I'm looking for a solution.  My own need here remains the same regardless of
what is decided about the intention wrt `expand*'s args.  I need a function that
has the latter behavior (but it need not be named `expand-file-name').

Besides a workable but ugly replace-regexp-in-string hack that saves and
restores consecutive slashes around a call to `expand-file-name', I don't see a
good way to do that.  In this case, consider this bug report a request for such
a function (enhancement request).

And also in this case - i.e., if it is decided that the input args must be
acceptable to the file system, that constraint on the args should be documented.
And we should say what the function does/returns otherwise (e.g., say that it is
undefined - i.e., that it is defined only in the case where the args are
acceptable names for the file system).  If we tell users that the args must be
of a form acceptable by the current file system, then we should also tell them
what happens otherwise (raise an error?...).