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

[Drew Adams]

> > _I_ sure wish it did.  I like using global-auto-revert-mode,
> > but that can make Emacs hang when it checks a remote file.
> > And since file-remote-p doesn't give the right answer ...
> 
> Is a file on a CDROM device that needs to spin up on every access
> file-remote-p?

We agree that we might need other test functions, such as Michael suggested.

But as long as the agreed-upon purpose of `file-remote-p' is to let you avoid an
access performance cost, that can be the place to incorporate such info.

IOW, either we add other test functions, as Michael suggested with
`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. Or we roll all the tests into some other function (as I
tried to do with `my-remote-file'), say, `slow-access-file-p'.

The expressed need is to know whether accessing a file with a given name might
be significantly slower than accessing a local file on an ordinary drive etc.

Some of those terms might be vague, but the general idea is clear: We want to
get a performance assessment from the file name (perhaps also locally checking
known mounts, mapped drives etc.) - without incurring a significant performance
penalty for the test itself. 

A boolean estimate is probably enough: possible performance hit vs probably
fast. How that is done, and whether it indicates that the file is remote or on a
slow local drive or whatever, I really don't care (but we might care, in some
contexts).

For some uses, some people might want more than a boolean - a time estimate, so
they can judge "fast enough" for some particular use. But for myself, now,
classifying the file names into two groups (probably fast, possibly slow) is
enough.