Re: testing for a remote file to include file on a Windows mapped drive

[Michael Albinus <michael.albinus@gmx.de>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So a file that does not have a handler is _never_ remote.
>
> That's irrelevant: look at the uses, and you'll see that most of them
> use file-remote-p in the sense described in the docstring, so all that's
> needed is to provide an implementation for the unhandled files.
>
> This may require some changes in file-relative-name, because this one
> does use file-remote-p in a more specific way, but everything else I've
> looked at uses file-remote-p as a way to test "fast&reliable or not".

I have available a checkout from April 7th. Scanning lisp/*, there are
40 places file-remote-p is called. Let's not regard the 17 calls of
tramp*.el, they could be replaced simply by another, Tramp internal,
function.

From the other 23 calls, I would count 5 calls related to the question
"Is the access slow"; the other calls are due to the file name handler
thingies, which require another implementation of the respective
functionality.

And, if you say that the calls of file-remote-p shall be replaced by
something else, which is closer to the file name handler
functionality: which function do you have in mind? Back in February,
you've spoken about file-local-name/unhandled-file-name. These
functions don't exist (yet).

Stefan, honestly: I don't understand why file-remote-p needs such a
redefinition. I assume there is a plan behind, which we don't know.
It would really be helpful if we could understand your intention of
this change.

One explanation, also in February, was that you want to have

(file-remote-p "file:///toto/titi") => nil

But with the same reasoning, you could say

(file-remote-p "/sudo:$USER@localhost:/toto/titi") => nil

And that doesn't work, IMHO.

>         Stefan

Best regards, Michael.