Re: Emacs-devel Digest, Vol 4, Issue 19

Re: Emacs-devel Digest, Vol 4, Issue 19

[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 "/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.

Re: Emacs-devel Digest, Vol 4, Issue 19

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> 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 "/".

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 "..".

What do you think?

For Tramp, filenames "/foo:bar" where "bar" is a relative name are
considered to be equivalent to "/foo:~/bar".

Ayee.  Once upon a time, Tramp would barf on "/foo:bar", but users
didn't want to type the extra two characters to use "/foo:~/bar"
instead.  So I fixed it up such that "/foo:bar" worked.  Now it's
haunting me, I think.

Anyhow, I think it is not a good idea to make "/foo:bar" and
"/foo:~/bar" different in such a subtle way.
-- 
A preposition is not a good thing to end a sentence with.

Re: Emacs-devel Digest, Vol 4, Issue 19

[Miles Bader]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
> 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 "..".

>From a user's point of view, I definitely agree.  Also with environment-
variables; I use names such as `$foo/../bar' quite often.

-Miles
-- 
We live, as we dream -- alone....

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 "/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.

Re: file-relative-name and remote files

[Lars Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 589 bytes --]

>
>
> Lars Hansen <larsh@math.ku.dk> writes:
>
>>> One more problem: The syntax to invoke the Tramp file handler
>>> is "\`/[^/:]+:". So the handler is not invoked in the call
>>> (expand-file-name "/emacs/../larsh@galois.math.ku.dk:."). The
>>> call returns "/larsh@galois.math.ku.dk:." but it should return
>>> "/larsh@galois.math.ku.dk:/home/l/larsh".
>>    
>>
>
>So maybe expand-file-name should re-invoke itself until it reaches a
>fixpoint?
> -- A preposition is not a good thing to end a sentence with.
>
IMHO expand-file-name should remove ".."'s *before* calling file
handlers.


[-- Attachment #1.2: Type: text/html, Size: 1539 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

>> Lars Hansen <larsh@math.ku.dk> writes:
>>
>>>> One more problem: The syntax to invoke the Tramp file handler
>>>> is "\`/[^/:]+:". So the handler is not invoked in the call
>>>> (expand-file-name "/emacs/../larsh@galois.math.ku.dk:."). The
>>>> call returns "/larsh@galois.math.ku.dk:." but it should return
>>>> "/larsh@galois.math.ku.dk:/home/l/larsh".
>>>    
>>
>>So maybe expand-file-name should re-invoke itself until it reaches a
>>fixpoint?
>> -- A preposition is not a good thing to end a sentence with.
>>
> IMHO expand-file-name should remove ".."'s *before* calling file
> handlers.

IMHO expand-file-name should expand "~" even before processing "..".
To expand "~" it is necessary to invoke the handler.

Hm.
-- 
A preposition is not a good thing to end a sentence with.