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

[Stefan Monnier]

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

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).

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

>> > 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 don't know.  Clearly ffap-file-remote-p is not considered as important
enough to be in the core.

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


        Stefan