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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Mon, 21 Apr 2008 22:46:49 -0400
> 
> > So a file that does not have a handler is _never_ remote.
> 
> That's irrelevant

Since when is the code irrelevant?  "Use the code, Luc" has been
always one of the slogans of free software, because code tells you
about what the software does much more than anything else.

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

You are reading too much into your own interpretation, IMO.  It's true
that file access via a handler is necessarily slower than via the
normal OS file APIs, but it doesn't mean the reverse is true: that any
slow file access is necessarily to a file for which file-remote-p
should return non-nil.

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

Like I said, it's a mystery to me why you insist on changing
file-remote-p for a different semantics.