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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <7617@debbugs.gnu.org>
> Date: Sun, 12 Dec 2010 14:35:20 -0800
> 
> 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?

For predictable behavior, the argument must have semantics of a valid
file name for the underlying filesystem.  In particular, a series of
slashes is interpreted as the filesystem would interpret them.

> 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.

If you seek suggestions for how to solve your problem in a non-ugly
way, please tell more about the problem.  It's clear that one
_solution_ to that problem is to have the old behavior of
expand-file-name.  But that behavior is gone and will not come back.
To suggest other solutions, we need to understand the problem.

> 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.

I think that saying "file names" is enough for a doc string--after
all, every programmer knows what is a valid file name.  The ELisp
manual says a few more words about that.  Putting this kind of detail
into a doc string of every file-oriented function would be excessive.

> 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?...).

If the argument doesn't have a valid file-name semantics, all bets are
off.