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

> From: Stefan Monnier <monnieriro.umontreal.ca>
> Cc: michael.albinusgmx.de,  emacs-develgnu.org, 
drew.adamsoracle.com,  jasonrgnu.org
> 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.