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

[Drew Adams]

> > I am using the function `expand*' on user input (one operation among
> > many), to do just what is advertised for `expand*'
> 
> There-s your problem.  You treat user input in a `read-file-name'
> as an actual file name (i.e. suitable to pass to functions like
> expand-file-name),

"Suitable to pass to functions like expand-file-name" is precisely the question
that you are begging.  That suitability is completely undefined so far.  Part of
this bug report asks that you document (a) just what is acceptable to
`expand-file-name' as "file-name" syntax (for each arg) and (b) what happens if
the arg is a string that is not of acceptable file-name syntax.

For (a) it is no doubt enough to say that it is whatever syntax is acceptable by
the current file system (if that is in fact the answer).  But that should be
stated explicitly, along with a description of (b).

> whereas it is actually a different beast, closely
> related, but different: it has this "..// -> /" and ".../~ -> 
> ~" rules, as well as env-var expansion (which also implies
> "$$ -> $" rewrite).  And even these special rules depend on
> file-name-handlers so, e.g., they do not apply to URLs but other
> rules may aaply to other special filenames.  I.e. the only safe
> thing to do is to first pass those strings through
> substitute-for-file-name.

Please read what I wrote.  I am looking for a function that gives the behavior
that is documented for `expand-file-name'.  That's all.

I do not want the slash-collapsing that also occurs but is (was before now)
undocumented.  And I do not want any of the input-transforming behavior provided
by `read-file-name' or `substitute-in-file-name'.  (I do not see any
`substitute-for-filename' function; I assume you meant `*-in-*'.)

In particular, I do not want ...// prefix removal or env var substitution.  I've
stated several times already that I am not looking for the behavior of
`substitute-in-file-name'.

If you do not regard the undocumented slash-collapsing of `expand-file-name' as
a bug, then I am obviously looking for a different function.  In any case, its
documented behavior (= the Emacs 20 behavior) is exactly what I am looking for.

Do you know a good way to get that behavior in Lisp?  I am getting it now by
calling `expand-file-name' within an envelope that restores any consecutive
slashes that get removed, but I'm looking for something less ugly.