bug#25183: 26.0.50; expanding quoted file name on w32

[Michael Albinus]

npostavs@users.sourceforge.net writes:

> Glenn Morris <rgm@gnu.org> writes:
>
>> Noam Postavsky wrote:
>>
>>>>>> (expand-file-name "/:~/path/./file")
>>>>>> => "/:~/path/file"
>>>
>>>>>> (expand-file-name "/:~/path/./file")
>>>>>> => "/:c:/Users/lb01177/AppData/Roaming/path/file"
>>>
>>>>
>>>> (file-name-absolute-p "/:~/path/./file")
>>>> => t
>>>
>>> I think all these cases are user error, `(emacs) Quoted File Names' says
>>>
>>>     You can "quote" an absolute file name [...] add '/:' at the beginning
>>>
>>> But you cannot quote a relative file name, which looks like what
>>> you're trying to do here. It might better to throw an error than
>>> return nonsense (though possibly not worth the trouble).
>>
>> But "~/blah" is an absolute file name. ?
>
> Yes, but in "/:~/blah", the /: should prevent expanding "~", so then it
> seems not to refer to an absolute file name, but rather a file named
> "blah" in a directory named literally "~".  But if it's not an absolute
> file name, then /: doesn't make sense.  So it's a kind of paradox.  This
> is not w32 specific (although the actual implementation happens to
> resolve the "paradox" in a different way on w32).

Well, I don't want to insist that it *must* be solved. But there's
different behaviour when running Emacs on GNU/Linux, or running on MS
Windows.

It is not an annoyance coming from a user's bug report; I've stumbled
over this when running tramp-tests.el under many different environments.

(expand-file-name "/:/~/path/./file") => "/:c:/~/path/file"

looks better, althoug the volume drive would still disturb me. But
that's my personal preference, the result might be OK on MS Windows.

Eli?

Best regards, Michael.