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

[Stefan Monnier]

> There are also `ediff-file-remote-p' and `ffap-file-remote-p', but
> they are not called from `file-remote-p'; they use this function instead.

(defun ediff-file-remote-p (file-name)
  (file-remote-p file-name))

As for ffap-file-remote-p, you're right, but it's just because
file-remote-p didn't exist back then.  Otherwise, it would also have
used file-remote-p.

BTW, when I said "The first is usually/always answered by calling
`file-remote-p'" I did not mean to say that file-remote-p always gives
the right answer, but that whenever someone needs to know this
information, they currently call file-remote-p.

> Maybe that is the major reason of our misunderstanding: I just read
> what is implemented (yet), and I can guess only what you want to have.

Instead, I look at the callers and try to guess what they want.
Since we're talking about deciding what file-remote-p should do, its
current implementation seems much less relevant.

> Stefan, maybe it is time to list en detail the required changes you
> have in mind for this?

Which changes?  The post you reply to is just as far as I've gotten in
trying to figure out what we should have.  I have no hidden plan in
this regard.

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

> "/:" is handled in `file-name-non-special', there is no problem wrt
> syscalls I believe.

There is: if you pass "/:/usr" to a syscall it will not find it.
I.e. wherever the file-name-handlers aren't used such a name will fail
(e.g. external processes, as well as a few cases internally, such as for
display properties specifying images by giving their file name, IIRC).

> "file:///foo" is a special case, indeed.

AFAIK, It's the exact same case as "/:".

> I have no idea, whether the implementation of `url-handler-mode' is
> complete (a year ago I've looked at the webDAV implementation, and it
> wasn't ready).

It's very much non-complete, but I use it all the time to access Elisp
or tarball packages on the web (they get displayed much better than in
Firefox, obviously), so it "does the job" for what I use it for.

> If I could understand better what needs to be done for url*.el, I
> would be willing to support. Is there a (prioritized) todo list what
> shall be done?

Not that I know.

>> 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.
> D'accord.

Wunderbar!


        Stefan