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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 21 Apr 2008 10:33:57 -0400
> Cc: 'Emacs-Devel' <emacs-devel@gnu.org>, Drew Adams <drew.adams@oracle.com>,
> 	'Jason Rumney' <jasonr@gnu.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.