Re: file-relative-name and remote files

[Lars Hansen]

> 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 "/address@hidden:../..", where the ~root on the remote host
> is "/root", the result will be "/address@hidden:/..", 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
"/address@hidden:/.." should be interpreted as it would on the remote machine,
i.e. "/address@hidden:/.." should normally expand to "/address@hidden:/".
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 "/address@hidden:/.." 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.