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

[Drew Adams]

> > Also, IIUC, `file-remote-p' isn't only boolean; the non-nil return value
> > means something. I don't know what should be returned for a
> > file on a mapped network drive.
>
> I'm not thrilled about the non-boolean return value of file-remote-p.
> Its semantics seem to be custom-tailored for Tramp and doesn't make so
> much sense in general :-(

Perhaps that other info should be relegated to some other function. Or
perhaps it should be local to Tramp, if it is not useful elsewhere.

At least for the use of `file-remote-p' that is to avoid possibly expensive
remote access, any info that might take more time to dig up should be left
out.

> > And should we perhaps have a function that distinguishes remote
> > files that are not on a mapped drive from those that are? Is
> > there any need to distinguish these? (We currently do distinguish
> > them, in that `file-remote-p' returns non-nil for the former and
> > nil for the latter.)
>
> It all depends what you want to know.  In doc-view, we recently tried to
> use file-remote-p in order to figure out whether we could pass the file
> name to a local process, only to discover that it wasn't the right
> predicate to use.  I replaced it later on with
> (let ((file-name-handlers-alist nil)) (file-readable-p <FILE>)).
>
> I think file-remote-p should really give a kind of performance and
> reliability info: is the file available from local (i.e. fast and
> reliable) storage, or is it only available via a network access which
> may be slow and may fail.

Yes, I think that is the most common use of `file-remote-p', in any case.
Whether that is, or needs to be, a true test of remoteness is another
question. If not, the name could perhaps be changed.

Typically, I think what's wanted in that use case is to just get an idea
whether the file name is likely to represent a remote file - info as to
whether or not the file is in fact remote is often not needed. For this
common use case, the function is in fact a sort of
`file-might-take-a-while-to-access-p' - it is not the remoteness that is as
important as the potential access time.

For example, if it takes actually connecting remotely to find out for sure
whether some file exists remotely, that is not appropriate for many current
uses of `file-remote-p', IIUC. At least, that was the use case I had in
mind: I don't want the function to take any extra time to find out for sure;
I just want to know if it is likely to be remote, in which case I will skip
certain operations.

> Now whether access via NFS should be considered as remote or not is not
> clear: it's ofen used for home directories, and treating all the user's
> file as "remote" is probably not a great idea.

I agree that the different notions of "remote" should be clarified, and one
should be able to obtain each of them that represents an important use case.

It is definitely useful to be able to distinguish "possibly remote" from
"local" in terms of potential performance impact - that is, regardless of
whether the meaning is truly remote vs local. I imagine that some of the
other distinctions might also be useful. Your use of `file-readable-p' for
doc-view would presumably be one of those.