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

> From: Stefan Monnier <monnieriro.umontreal.ca>
> Date: Mon, 21 Apr 2008 10:33:57 -0400
> Cc: 'Emacs-Devel' <emacs-develgnu.org>, Drew Adams
<drew.adamsoracle.com>,
> 	'Jason Rumney' <jasonrgnu.org>
> 
> Please read the docstring of file-remote-p, it has
"nothing" to do
> with the above.  What you describe can misclassify both
ways: remote
> access can be provided by the OS (using
NFS/AFS/SSHFS/...), and local
> access can be provided by file-name-handlers (e.g.
file:// URLs).

That may be how you _want_ it to be, but the current
implementation
does not live up to this intent, and it (the current
implementation)
is sufficiently old to have everybody and their dog become
accustomed
to the peculiar interpretation of the term ``remote'' in
Emacs.
Here's the current code in Emacs 23:

    (defun file-remote-p (file &optional identification
connected)
    "..."
    `file-remote-p' will never open a connection on its
own."
      (let ((handler (find-file-name-handler file
'file-remote-p)))
	(if handler
	    (funcall handler 'file-remote-p file identification
connected)
	  nil)))

So a file that does not have a handler is _never_ remote.

Unless and until we change that, this whole argument based
on the doc
string is purely academic.  OTOH, those who are accustomed
to the
current notion of ``remote'', meaning there's a file handler
somewhere
in Emacs, will probably be surprised if it starts returning
non-nil
for NFS-mounted volumes some day.

That is why I agree with Michael that a new primitive is in
order.
Why you insist on changing the semantics of `file-remote-p'
is a
mystery to me.