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

[Drew Adams]

> >> > Could someone please summarize what was done about this?
> >> Nothing.
> 
> > Could you (someone) explain why nothing was done? Was it because it
> > was decided that: It was a silly problem and request (no need)? No
> > idea how to fix it? No resources to fix it? Someone is still working
> > on it?
> 
> 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?

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

> > What about the question wrt `file-remote-p' and `ffap-remote-p'?
> 
> ffap-file-remote-p seems to be incompatible with file-remote-p because
> it is also used to "normalize" file names and is applied to URLs even
> when url-handler-mode is not loaded.
> 
> Maybe we should add to file-remote-p something equivalent to
> ffap-rfs-regexp.

That was part of the suggestion/question: whether I should really need to call
two functions that way. I do so because it seemed to me that neither alone was
adequate to the task of telling me whether a file name might be remote. I try
ffap-file-remote-p first, because that seems less costly. 

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?