RE: testing for a remote file to include file on aWindows mappeddrive

[Drew Adams]

> > `file-mounted-p', and you then test with (or ...) to see if there is
> > a possible slowdown, or we put the tests into `file-remote-p' and we
> > recognize that the name is not accurate.
> 
> Drew.  *Please* read the new docstring:

Please reread what you just quoted - "or we put the tests into `file-remote-p'".
IOW, I'm OK with that approach. And I don't really care whether the function
name is accurate. It's what the function does that is the topic of discussion.

>    A file is considered "remote" if accessing it is likely to 
>    be slower or less reliable than accessing local files.
> 
> Physical remoteness is irrelevant.  Even the transport protocol might
> not be relevant sometimes (tho it can be good input to a default
> heuristic).  The current implementation and behavior is not cast
> in stone.

I have no problem with that. I specifically said it would be OK to do any of the
following:

1. Put the other tests into `file-remote-p', so that it is a general test of
likely fast/slow file access.

2. Add other functions to treat other kinds of fast/slow determination from
remoteness.

3. Do #1 and perhaps rename `file-remote-p'.

Again, I have no problem with continuing to call it `file-remote-p' and beefing
it up to take into account some of the other slowness considerations people have
mentioned. My only need for now is to have a function that does that.