Re: file-relative-name and remote files

[Richard Stallman]

    One more problem: The syntax to invoke the Tramp file handler
    is "\`/[^/:]+:". So the handler is not invoked in the call
    (expand-file-name "/emacs/../address@hidden:."). The
    call returns "/address@hidden:." but it should return
    "/address@hidden:/home/l/larsh".

I am not sure whether "/address@hidden:." is correct, but it
might be.  I don't think it should return
"/address@hidden:/home/l/larsh" because that requires
contacting the remote host, and it is better if expand-file-name does
its work locally.

    Btw, if the part after the colon is not an absolute filename, that is
    interpreted as being relative to the remote home dir.  What happens
    if I open a file "/foo:../bar"?  Is that the same as "/foo:/../bar"
    and therefore the same as "/bar"?

It isn't the same as "/foo:/../bar", just as
"/foo:bar" is not equivalent to "/foo:/bar".

Hmm, this raises the issue of what expand-file-name should do with
"/foo:../..".  I guess it must leave that unchanged, which means that
the expand-file-name handler for these file names should be rather
careful in what it does to simplify whatever part of the name comes
after.  It is not correct to simplify /X/../Y into /Y when /X
is a remote prefix.

This seems to have implications about file-relative-name.  Suppose we
ask for

  (file-relative-name "/a/b" "/address@hidden:../../")

I think in this case there is no correct relative file name that it
could return.  The only correct value to return is an absolute file
name in this case.

This seems to prove that the proposed change in file-relative-name
should be made.