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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I have available a checkout from April 7th. Scanning lisp/*, there are
> 40 places file-remote-p is called. Let's not regard the 17 calls of
> tramp*.el, they could be replaced simply by another, Tramp internal,
> function.

> From the other 23 calls, I would count 5 calls related to the question
> "Is the access slow"; the other calls are due to the file name handler
> thingies, which require another implementation of the respective
> functionality.

Looking at it again, I see that it is a bit less uniform than
I remembered, indeed.

> And, if you say that the calls of file-remote-p shall be replaced by
> something else, which is closer to the file name handler
> functionality: which function do you have in mind? Back in February,
> you've spoken about file-local-name/unhandled-file-name. These
> functions don't exist (yet).

> Stefan, honestly: I don't understand why file-remote-p needs such a
> redefinition.  I assume there is a plan behind, which we don't know.
> It would really be helpful if we could understand your intention of
> this change.

I have no idea which change you're talking about.
I just have noticed several different concerns that tend to be
conflated:
- reliability and performance.
- ability to access the file via syscalls.
- whether relative file names can be used from one file name to another.
- whether a file's contents is directly accessible via syscalls.

The first is usually/always answered by calling `file-remote-p'.

The second is sometimes answered by calling file-remote-p, although it
does not give the right answer for /:/foo, and it clashes with the
previous use of file-remote-p if you want to say that "file://" is
not remote.  A closer match for this is unhandled-file-name-directory,
except that it historically didn't give useful information (it typically
returned /tmp rather than nil for handled file names) and it only
works for directories.

The third is currently answered by file-remote-p.  It's only used in
file-relative-name, AFAIK, so it doesn't matter much where the info
comes from, as long as file-relative-name is updated accordingly.
In any case abusing file-remote-p for that seems like a bad idea.

The last one is relevant for compressed files, encrypted files, and
files extracted from tar/zip/ar/rar/... archives.  This is usually
answered by a bunch of ad-hoc tests listing all the situations of which
the author was aware.  E.g. it'll need update for auto-encryption-mode.
We should introduce a new function for that.  Something like
unhandled-file-contents.  OTOH unhandled-file-contents can only return
non-nil if unhandled-file-name is non-nil, so maybe we should combine
the two, and use an argument `contents' to indicate whether we only care
about accessing the file (container) via syscalls or accessing also
its contents.

> One explanation, also in February, was that you want to have
> (file-remote-p "file:///toto/titi") => nil
> But with the same reasoning, you could say
> (file-remote-p "/sudo:$USER@localhost:/toto/titi") => nil
> And that doesn't work, IMHO.

I don't have a strong opinion on "/sudo:$USER@localhost:/toto/titi":
I think it would be OK to return nil, but non-nil is OK as well: access
via sudo is probably slower and may even require user-input.
I'm not sure why you say it wouldn't work to return nil for it.


        Stefan