Tramp/Ange-FTP filename unification

Tramp/Ange-FTP filename unification

[Kai Großjohann]

I think I've now done it so that it works.  The new filename format
is this:

Normal:
    /method:user@host:/path/to/file
Multi-hop:
    /multi:hopm1:user1@host1:hopm2:user2@host2:/path/to/file

In the normal filename format, the method and user are optional.

In the multi-hop format, all methods must be given, both the initial
"multi" or "multiu" which decides between base64 and uuencode, and
the hop methods hopm1, ..., hopmK.

What's currently unclean is that Ange-FTP adds its stuff to
file-name-handler-alist and then Tramp removes it again.  This is the
next step I want to do: just comment out the code in Ange-FTP which
adds to file-name-handler-alist and disable the removing code in
Tramp.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp/Ange-FTP filename unification

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> I think I've now done it so that it works.  The new filename format
> is this:
> 
> Normal:
>     /method:user@host:/path/to/file
> Multi-hop:
>     /multi:hopm1:user1@host1:hopm2:user2@host2:/path/to/file

Using `:' for both separators makes filenames with omitted components
more ambiguous.  I thought there was pretty much a consensus to use `#'
to delineate the method (either as a post- or prefix); why did you
change it?  [More importantly, why did you change it unilaterally?]

> In the multi-hop format, all methods must be given, both the initial
> "multi" or "multiu" which decides between base64 and uuencode, and
> the hop methods hopm1, ..., hopmK.

Why?

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Tramp/Ange-FTP filename unification

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> I think I've now done it so that it works.  The new filename format
>> is this:
>> 
>> Normal:
>>     /method:user@host:/path/to/file
>> Multi-hop:
>>     /multi:hopm1:user1@host1:hopm2:user2@host2:/path/to/file
>
> Using `:' for both separators makes filenames with omitted components
> more ambiguous.

Well, the filename "/method:/path/to/file" does not make sense IMHO.
Tramp is for editing remote files, you should always specify at least
a host name.  So in a filename like "/x:y", the x will be interpreted
as a host name.

Do you think that's bad?

> I thought there was pretty much a consensus to use `#' to delineate
> the method (either as a post- or prefix); why did you change it?

Well, err...  I didn't think that it was a problem which character to
use, as long as the total number of characters with special meaning
does not increase.

Another problem is that the design of regular expressions for the
multi-hop methods is a bit unfortunate, so that either each hop must
start with the same character, or each hop must end with the same
character.  And if I use the colon throughout then all hops,
including the first one, begin with a colon.

> [More importantly, why did you change it unilaterally?]

Maybe because I didn't expect any opposition.

In the end, I changed to `:' because it's prettier and easier to type.
But if general consensus is that `#' is prettier or easier to type or
whatever then of course, the regexp can be changed.  No problemo.

>> In the multi-hop format, all methods must be given, both the initial
>> "multi" or "multiu" which decides between base64 and uuencode, and
>> the hop methods hopm1, ..., hopmK.
>
> Why?

Because of limitations in the implementation: the autodetection is
not yet implemented.

For the hop methods, it is not practicable to implement
autodetection, as that would mean to attempt various kinds of
connections at each step.  And unless you guess right at the first
attempt, long timeouts will result.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp/Ange-FTP filename unification

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> >>     /method:user@host:/path/to/file
> >
> > Using `:' for both separators makes filenames with omitted components
> > more ambiguous.
> 
> Well, the filename "/method:/path/to/file" does not make sense IMHO.
> Tramp is for editing remote files, you should always specify at least
> a host name.  So in a filename like "/x:y", the x will be interpreted
> as a host name.

What about methods that just su?  There doesn't seem to be any reason
why tramp should be only for remote files; it's really a way of editing
through a shell connection, with remote shells being a particularly
common and handy subset of that functionality.

> Do you think that's bad?

Well, I think that it's good that X in `/X:Y' will be interpreted as a
hostname, but it seems desirable to be able to specify a `method-only'
name for methods where a hostname doesn't make any sense.

Maybe `:' _is_ the right choice, and something like `/M::P' should be
required for method-only names, but I think it deserves some discussion.

-Miles
-- 
97% of everything is grunge

Re: Tramp/Ange-FTP filename unification

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Maybe `:' _is_ the right choice, and something like `/M::P' should be
> required for method-only names, but I think it deserves some discussion.

So maybe we can do multi-tasking: we discuss and test whether the
functionality works at the same time.

I did not build a feature into Tramp to accept empty or omitted host
names, by the way.  I have no idea what happens if you try...

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp/Ange-FTP filename unification

[Kim F. Storm]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> > Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> >> I think I've now done it so that it works.  The new filename format
> >> is this:
> >> 
> >> Normal:
> >>     /method:user@host:/path/to/file
> >> Multi-hop:
> >>     /multi:hopm1:user1@host1:hopm2:user2@host2:/path/to/file
> >
> > Using `:' for both separators makes filenames with omitted components
> > more ambiguous.
> 
> Well, the filename "/method:/path/to/file" does not make sense IMHO.
> Tramp is for editing remote files, you should always specify at least
> a host name.  So in a filename like "/x:y", the x will be interpreted
> as a host name.
> 
> Do you think that's bad?

Like Miles, I was worried at first, but I think the new syntax makes sense.

In any case, the "long style syntax" wouldn't really matter if tramp
handles "host abbrevs" so that writing /xyz:/ is automagically
expanded to /multi:m1:u1@h1:m2:u2@u2:/ (behind the scenes please)
whenever it is used.

This will also allow me to make an abbrev /su:/ to do "su root" on my
own machine by expanding to /su:root@localhost:/.

So is tramp-abbrevs implemented yet?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Tramp/Ange-FTP filename unification

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> So is tramp-abbrevs implemented yet?

No :-(

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Tramp/Ange-FTP filename unification

[Juanma Barranquero]

I'm getting a strange problem with ido.el completions that could be
related to recent changes to Ange-FTP/Tramp.

For example:

(current directory: c:/bin/emacs/HEAD/bin)
emacs -q --no-site-file
M-x ido-mode
C-x C-f      => Prompt is "Find file: c:/bin/emacs/HEAD/bin/"
<backspace>  => "c:/bin/emacs/HEAD/"
<backspace>  => "c:/bin/emacs/"
<backspace>  => "c:/bin/"
<backspace>  => "c:/" and <backspace> does not delete the c:/ part
<right>      => "c:/{CONFIG.SYS | ...} [No match]"
<right>      => "c:/{CONFIG.SYS | ...} [No match] [No match]" etc.

                                                           /L/e/k/t/u

Re: Tramp/Ange-FTP filename unification

[Juanma Barranquero]

On 12 Jul 2002 17:34:27 +0200, storm@cua.dk (Kim F. Storm) wrote:

> What is returned by
> 
>   M-x (file-name-all-completions "" "c:/") RET 

Something sensible: the list of all files and directories in the root of
the drive.


                                                           /L/e/k/t/u

Re: Tramp/Ange-FTP filename unification

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> I'm getting a strange problem with ido.el completions that could be
> related to recent changes to Ange-FTP/Tramp.
> <right>      => "c:/{CONFIG.SYS | ...} [No match]"
> <right>      => "c:/{CONFIG.SYS | ...} [No match] [No match]" etc.
>

Could very well be tramp tramping all over ido :-)

What is returned by

  M-x (file-name-all-completions "" "c:/") RET 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Tramp/Ange-FTP filename unification

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> I'm getting a strange problem with ido.el completions that could be
> related to recent changes to Ange-FTP/Tramp.
> 

I don't know whether this is tramp related, but some change made during the
last 24 hours has made ido not work at all.

It seems that something is messing with the minibuffer, since the
extra info ido is putting in the minibuffer after the user input is 
all of a sudden converted into user input, e.g. as if expand-file-name
was called in the minibuffer.

Does this ring a bell, anyone?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Tramp/Ange-FTP filename unification

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> > I don't know whether this is tramp related, but some change made during the
> > last 24 hours has made ido not work at all.
> > 
> > It seems that something is messing with the minibuffer,
> 
> Yes. It also affects icomplete, for example. I´ve had to disable both.
> 


Ok, I tracked it down to a bug in the new "Vmemory_full" handling.
The check in command_loop_1 was the wrong way round, so it never
ran any post-command-hooks *unless* memory was full...

I just committed a fix.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Tramp/Ange-FTP filename unification

[Juanma Barranquero]

> I don't know whether this is tramp related, but some change made during the
> last 24 hours has made ido not work at all.
> 
> It seems that something is messing with the minibuffer,

Yes. It also affects icomplete, for example. I´ve had to disable both.

> Does this ring a bell, anyone?

I´ve changed a obscure function (timer-set-time-with-usecs, from
timer.el) and at first feared the problem was related to that change
(because the error happens after a small delay, when the completions are
processed), but I´ve tested reverting the change and there seems to be
no connection whatsoever. Not that I expected it: AFAICS, there´s not a
single call to timer-set-time-with-usecs neither in Lisp nor C code
anywhere in Emacs.


-- 
Juanma Barranquero <lektu@terra.es>