Re: file-relative-name and remote files

[Lars Hansen]

> Richard has decided that ".." shall not be used to cross file handler
> boundaries.  So file-relative-name needs to be changed to something
> like Lars suggested.
>
> I have some comments/questions about this implementation.
>
> Why the extra arg SEPARATE-TREES?  If I understand Richard correctly,
> he wants file-relative-name to always behave as if SEPARATE-TREES was
> true.
I agree, that parameter should be removed.
> > >                   (equal
> > >                     (and
> > >                       (string-match re filename)
> > >                       (substring filename 0 (match-end 0)))
> > >                     (and
> > >                       (string-match re directory)
> > >                       (substring directory 0 (match-end 0)))))))))
> >   
>
> I'm not sure it's a good idea to check this stuff here.  Maybe it
> would be better to let each filename handler do that.
>
> For example, Tramp has the concept of a default method, so
> /address@hidden:/file and /ssh:address@hidden:/file denote the same file by
> default, even though the strings are different.
>
> It seems to me that it is better to let the handler decide.
I don't see a problem. My implementation calls expand-file-name on
filename as well as directory. I guess that should expand
"/address@hidden:/file" to e.g. "/ssh:address@hidden:/file". Am I wrong?