Re: file-relative-name and remote files

[Richard Stallman <rms@gnu.org>]

    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?

I wouldn't say it is wrong, but it has a drawback: expanding the
remote ~/ requires getting info from the remote machine, which is
slow (for this operation).

I don't see an obvious better alternative, though.

    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?

They both make logical sense, and the second is much easier for Emacs
to implement, but I think the former is more useful.

    That just doesn't make sense.  It neglects "~".  IMHO, a filename
    such as "~/../bla" makes perfect sense, and I think that "~" should
    be expanded first, before processing "..".

It doesn't address the question of what to do with "~", but I would not
say that makes it nonsense.

expand-file-name does handle "~" the way you suggest.

    But Richard wants to allow ".." to cross file handler boundaries.
    So "/foo:/../bar" should expand to "/bar", just like "/foo/../bar"
    does.

That's what I thought at first, but in my last message on this issue
I recognized the arguments for the other side.

    One approach that might work is this: if expand-file-name does not
    find a handler, it does its thing and then looks again if it finds a
    handler.  Then it invokes that.

I guess that is necessary.  However, once expand-file-name has found
and called one handler, I hope it can avoid looking for another
handler.