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

[Drew Adams]

> >> AFAIK, it's a difficult problem, and it's not very high up on the
> >> priority.
> > I see. Would it help for me to detail my use case more?
> 
> Maybe.  Try to phrase it in terms of the docstring of file-remote-p,
> either showing how the function's implementation falls short 
> of its spec, or that the spec is not adequate for your use (maybe we
> need another function for that, or maybe the spec can be adjusted).

As you said, the purpose of file-remote-p is to determine, without the cost of a
remote access, whether a file name represents a remote file. The aim in using it
is to be able to know that a file is remote, so you might then avoid the cost of
accessing it.

* A file on a Windows mapped network drive is remote, in the sense of incurring
a performance penalty for access. `file-remote-p' should return non-nil for such
a file, but nil for a file on a Windows local drive. That is not the case now.

* `file-remote-p' does not handle some file-name cases handled by
`ffap-file-remote-p', or it handles them less efficiently. It should incorporate
the syntactic file-name matching that `ffap-file-remote-p' does.

Again, I can detail my use case, to show why this is important to me, if it will
help.

> >> > Assuming for the moment that there is no intention to do anything
> >> > about it, can someone at least weigh in on the code I sent 
> >> > (which I'm still using)?  Suggestions for improvement?
> > No?
> 
> No idea what code you're talking about.

I sent it at least three times in this thread, including this morning. Again:

> (defun my-file-remote-p (file)
>   "Non-nil means FILE is likely to name a file on a remote system.
> For MS Windows, this includes a file on a mapped network drive."
>   (or (and (eq system-type 'windows-nt)
>            (let ((case-fold-search t))
>              (and (string-match "\\`\\([a-z]:\\)" file)
>                   (eq 0 (condition-case nil
>                             (call-process
>                              shell-file-name nil nil nil
>                              shell-command-switch
>                              (concat "NET USE "
>                                      (match-string 1 file)))
>                           (error nil))))))
>       (and (fboundp 'ffap-file-remote-p)
>            (ffap-file-remote-p file))
>       (file-remote-p file)))

FWIW, Michael Albinus tested that code against `file-remote-p' for one remote
file name. He came up with these times on a Ubuntu machine using Emacs 23.0.60
and Tramp 2.1.13 (so, without using the Windows NET USE part):

 (elp-instrument-function 'icicle-file-remote-p)
 (dotimes (i 1000)
   (icicle-file-remote-p "/ssh:address@hidden"))
 
 (elp-results)
 icicle-file-remote-p  1000  0.0111750000  1.117...e-05
 
 (elp-instrument-function 'file-remote-p)
 (dotimes (i 1000)
   (file-remote-p "/ssh:address@hidden"))
 
 (elp-results)
 file-remote-p  2004  1.4309400000  0.0007140419

So for at least some remote file names `ffap-file-remote-p' is quite a bit
faster than `file-remote-p' (`icicle-file-remote-p' here is what I called
`my-file-remote-p' above).

[Apologies, Michael, for quoting off-list mail; I assumed you wouldn't mind.]

> >> Maybe we should add to file-remote-p something equivalent to
> >> ffap-rfs-regexp.
> 
> > I use ffap-file-remote-p only for matching the two regexps, not for
> > its returned string value. Why do you mention only 
> > ffap-rfs-regexp and not also ffap-ftp-regexp?
> 
> ffap-rfs-regexp seems to fall squarely in the domain of file-remote-p.
> ffap-ftp-regexp should already be handled by ange-ftp's definition of
> file-remote-p.

So if ffap-ftp-regexp is subsumed by an ange-ftp test, the question becomes
whether that ange-ftp test should be included in `file-remote-p'.