Re: file-relative-name and remote files

[Lars Hansen <larsh@math.ku.dk>]

>
>
>Actually, what Tramp does to expand "/foo:../.." is the following:
>
>* The localname part ("../..") is not absolute, so it must be relative
>  to the remote home dir.  Prepend "~/" to the localname, giving
>  "/foo:~/../..".
>
>* Expand tildes, giving, say, "/foo:/home/jrl/../..".
>
>* Expand the localname part, giving "/", then tack on the prefix.
>
>The final result is "/foo:/".
>
>Is this the right behavior so far?
>
>
>
>In the case of "/root@foo:../..", where the ~root on the remote host
>is "/root", the result will be "/root@foo:/..", which is not pretty.
>Maybe this should be expanded, again, to "/".  WDYT?
>  
>
One might look at file name in the following two ways:

1. An optional remote prefix followed by something.
2. A sequence of strings separated by slashes.

Which view should be given highest precedence?

If the first view is given the highest precedence, I think the "/.." part of
"/root@foo:/.." should be interpreted as it would on the remote machine,
i.e. "/root@foo:/.." should normally expand to "/root@foo:/".
In this case a file cannot be named relative to a directory if the file and
the directory are on different machines.

If the second view is given the highest precedence, "/x/.." should expand
to "/" independently of what "x" is. Thus "/root@foo:/.." as well
as "/foo:../.."
should expand to "/".
In this case a file can always be named relative to a directory.
In this case expand-file-name should be changed to remove ".."'s *before*
file handlers are called.

IMHO the two choises of precedence should not be mixed.