Re: file-relative-name and remote files

[Lars Hansen]

> But Richard wants to allow ".." to cross file handler boundaries.
> So "/foo:/../bar" should expand to "/bar", just like "/foo/../bar"
> does.
>
> I think that means we're back to square one and we need to find out
> how to deal with things like "/bla/../foo:/bar".  Hm.  Actually, that
> expands to "/foo:/bar" which is fine.  But "/bla/../foo:../bar"
> expands to "/foo:../bar" which is not fine -- it should be expanded
> further.
>
> 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.
>
> (Maybe it is easier to implement the previous paragraph by saying,
> after expand-file-name has done its thing in the non-handler case, it
> just reinvokes itself.)
>  
Ok, I think I begin to get the right view of things.
If it is still not right, please correct me.

We want to use the file name handler mecanism to make the directory tree
of a remote machine appear as if it was on the local machine in
directory "/foo:". This works by now except that "/bla/../foo:" is not
handeled correctly, because the file handler is not invoced.

Maybe the "/bla/../foo:" problem could be solved the following way:
Change the file handler syntax from "^/[^/:]+:" to "/[^/:]+:" to invoke
Tramp. Let Tramp call expand-file-name on "/bla/..". If this expands to
"/" everything is fine, otherwise barf.