Emacs unconditionally loads tramp.el

Emacs unconditionally loads tramp.el

[Romain Francoise]

With a CVS build of a few minutes ago, Emacs seems to load tramp.el
unconditionally:

(./emacs -Q)
For information about the GNU Project and its goals, type C-h C-p.
Loading tramp...
Loading regexp-opt...done
Loading tramp...done

on GNU Emacs 22.0.50.44 (i686-pc-linux-gnu, GTK+ Version 2.8.17)
 of 2006-04-24 on pacem

I think this might be related to this change:

2006-04-23  Michael Albinus  <michael.albinus@gmx.de>

	* net/tramp.el (tramp-register-file-name-handlers): New defun.
	Added with autoload cookie.
	(tramp-unload-file-name-handlers): Renamed from
	`tramp-unload-file-name-handler-alist'.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Romain Francoise <romain@orebokech.com> writes:

> With a CVS build of a few minutes ago, Emacs seems to load tramp.el
> unconditionally:

That's right. It is due to `tramp-register-file-name-handlers' in
`emacs-startup-hook', which is an autoloaded function. But Tramp would
be loaded anyway when one tries to complete a filename in the
minibuffer, because the intention of my change is to provide
method/username/hostname completion for remote files. "C-x C-f / <TAB>"
would be sufficient to load Tramp.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Romain Francoise]

Michael Albinus <michael.albinus@gmx.de> writes:

> That's right. It is due to `tramp-register-file-name-handlers' in
> `emacs-startup-hook', which is an autoloaded function. But Tramp would
> be loaded anyway when one tries to complete a filename in the
> minibuffer, because the intention of my change is to provide
> method/username/hostname completion for remote files. "C-x C-f / <TAB>"
> would be sufficient to load Tramp.

In that case, tramp.el and regexp-opt should probably be preloaded,
rather than be loaded every time via `emacs-startup-hook'.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Romain Francoise <romain@orebokech.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> That's right. It is due to `tramp-register-file-name-handlers' in
>> `emacs-startup-hook', which is an autoloaded function. But Tramp would
>> be loaded anyway when one tries to complete a filename in the
>> minibuffer, because the intention of my change is to provide
>> method/username/hostname completion for remote files. "C-x C-f / <TAB>"
>> would be sufficient to load Tramp.
>
> In that case, tramp.el and regexp-opt should probably be preloaded,
> rather than be loaded every time via `emacs-startup-hook'.

... or revert the change to the previous behaviour: method/ username/
hostname completion are active only after loading the first remote
file. I'm really undecided what's better.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Stefan Monnier]

>> In that case, tramp.el and regexp-opt should probably be preloaded,
>> rather than be loaded every time via `emacs-startup-hook'.
> ... or revert the change to the previous behaviour: method/ username/
> hostname completion are active only after loading the first remote
> file. I'm really undecided what's better.

Or do as ange-ftp does: only load the completion code when the user hits TAB
at something like "/".  After all, it's rather uncommon to do that (at least
for me) unless I use Tramp.


        Stefan

Re: Emacs unconditionally loads tramp.el

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Or do as ange-ftp does: only load the completion code when the user
> hits TAB at something like "/".  After all, it's rather uncommon to do
> that (at least for me) unless I use Tramp.

Yes, that would be even better.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> In that case, tramp.el and regexp-opt should probably be preloaded,
>>> rather than be loaded every time via `emacs-startup-hook'.
>> ... or revert the change to the previous behaviour: method/ username/
>> hostname completion are active only after loading the first remote
>> file. I'm really undecided what's better.
>
> Or do as ange-ftp does: only load the completion code when the user hits TAB
> at something like "/".  After all, it's rather uncommon to do that (at least
> for me) unless I use Tramp.

That's what I've tried first. But this fails dumping with temacs (see
corresponding thread some days ago).

The reason that I fail with this approach (and ange-ftp succeeded) is
that `tramp-completion-file-name-handler´ is defined in tramp.el, but
`ange-ftp-completion-hook-function´ is defined in files.el. That's why
temacs tries to load tramp.el ...

No, I don't request that `tramp-completion-file-name-handler´ must be
moved to files.el or suchalike. I could live with the behaviour that
hostname completion is active after loading the first remote file
only. That's the behaviour we've got for years, and nobody did
complain.

>         Stefan

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Richard Stallman]

    The reason that I fail with this approach (and ange-ftp succeeded) is
    that `tramp-completion-file-name-handlerŽ is defined in tramp.el, but
    `ange-ftp-completion-hook-functionŽ is defined in files.el. That's why
    temacs tries to load tramp.el ...

I moved it to files.el specifically to solve the analogous
problem for ange-ftp.

So how about if move the Tramp completion function to files.el
in the same way?

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> So how about if move the Tramp completion function to files.el
> in the same way?

That would solve this problem. `tramp-completion-file-name-handler´ is
sufficiently stable (last change on 2002-10-11). Shall I apply this patch?

There's still the remaining issue whether it is _desired_ to load tramp
on ordinary file name completion. Here I could imagine a customization
for that feature. Default ON or OFF depends on convenience for the
_majority_ of users. I would vote for ON, but maybe I'm biased.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Stefan Monnier]

>> So how about if move the Tramp completion function to files.el
>> in the same way?

> That would solve this problem. `tramp-completion-file-name-handler´ is
> sufficiently stable (last change on 2002-10-11). Shall I apply this patch?

BTW if you'd rather keep all the code in tramp.el rather than spread a bit
of it in files.el, you can use the ;;;###autoload trick.

That is, place in tramp.el either

;;;###autoload (defun tramp-completion-file-name-handler (operation &rest args)
;;;###autoload   "Invoke tramp file name completion handler.
;;;###autoload Falls back to normal file name handler if no tramp file name handler exists."
;;;###autoload ;;   (setq tramp-debug-buffer t)
;;;###autoload ;;   (tramp-message 1 "%s %s" operation args)
;;;###autoload ;;   (tramp-message 1 "%s %s\n%s"
;;;###autoload ;; 		 operation args (with-output-to-string (backtrace)))
;;;###autoload   (let ((fn (assoc operation tramp-completion-file-name-handler-alist)))
;;;###autoload     (if fn
;;;###autoload 	(save-match-data (apply (cdr fn) args))
;;;###autoload       (tramp-completion-run-real-handler operation args))))

or

;;;###autoload
(progn
 (defun tramp-completion-file-name-handler (operation &rest args)
  "Invoke tramp file name completion handler.
Falls back to normal file name handler if no tramp file name handler exists."
;;   (setq tramp-debug-buffer t)
;;   (tramp-message 1 "%s %s" operation args)
;;   (tramp-message 1 "%s %s\n%s"
;; 		 operation args (with-output-to-string (backtrace)))
  (let ((fn (assoc operation tramp-completion-file-name-handler-alist)))
    (if fn
	(save-match-data (apply (cdr fn) args))
      (tramp-completion-run-real-handler operation args)))))

so that the complete function gets copied to loaddefs.el (not just a short
`autoload statement).  We use this in vc-*.el so that the code that
determines whether a file is under CVS or not can be in vc-cvs.el and
preloaded even though vc-cvs.el is not itself preloaded.


        Stefan

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> BTW if you'd rather keep all the code in tramp.el rather than spread a bit
> of it in files.el, you can use the ;;;###autoload trick.

Thanks a lot! With this recipe, I could apply a fix that Tramp is not
loaded during Emacs startup.

>         Stefan

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Richard Stallman]

    There's still the remaining issue whether it is _desired_ to load tramp
    on ordinary file name completion.

I do not understand the question.  Would you please show me the precise
scenario in which you propose Tramp should be loaded?

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     There's still the remaining issue whether it is _desired_ to load tramp
>     on ordinary file name completion.
>
> I do not understand the question.  Would you please show me the precise
> scenario in which you propose Tramp should be loaded?

"/" matches `tramp-completion-file-name-regexp'. Any single
(expand-file-name "/") loads Tramp after my recent changes.

That's not new, because it's a similar story with Emacs 21 and
`ange-ftp-completion-hook-function'. The only difference is that
Ange-FTP is loaded only for `file-name-completion´, whereas
Tramp is loaded in more cases.

I was thinking about a customer option, which let's the user decide
whether (s)he wants Tramp hostname completion. If decided for NO,
Tramp would be loaded only when a remote file is requested.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Fri, 28 Apr 2006 06:26:59 +0200
> Cc: romain@orebokech.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> "/" matches `tramp-completion-file-name-regexp'. Any single
> (expand-file-name "/") loads Tramp after my recent changes.

It's a nuisance to have a large package load whenever I type an
absolute file name and press TAB after typing a part that contains
only one slash.  Not only does it take time, it also causes the part I
typed to be obscured by the "Loading WHATEVER...done" message; I need
to type some key to get that message erased without having to wait for
its timeout.

Can we talk about this (mis)feature, and maybe find a less annoying
solution for whatever problem it is trying to solve?

> That's not new, because it's a similar story with Emacs 21 and
> `ange-ftp-completion-hook-function'.

It was annoying in ange-ftp as well.  There's no need to keep old
annoyances.

> The only difference is that Ange-FTP is loaded only for
> `file-name-completion´, whereas Tramp is loaded in more cases.

So it's even more annoying in Tramp, IMO.  Just typing "C-x C-f /",
without even a TAB, loads Tramp and regex-opt.

> I was thinking about a customer option, which let's the user decide
> whether (s)he wants Tramp hostname completion.

Can we perhaps take the hostname completion part out of Tramp (and out
of ange-ftp) and have it preloaded?

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Can we perhaps take the hostname completion part out of Tramp (and out
> of ange-ftp) and have it preloaded?

Likely not (that means "only with serious reordering of the
code"). It's too much code, and too much linked with the rest.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: romain@orebokech.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 28 Apr 2006 22:01:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can we perhaps take the hostname completion part out of Tramp (and out
> > of ange-ftp) and have it preloaded?
> 
> Likely not (that means "only with serious reordering of the
> code"). It's too much code, and too much linked with the rest.

How come it's so complex?

Can you please point me to the right function in Tramp's sources?  I'd
like to understand why it is so hard to complete on host names.

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you please point me to the right function in Tramp's sources?  I'd
> like to understand why it is so hard to complete on host names.

Look for "tramp-completion-*". It's not only host names, but also
methods and user names which need to be expanded. And what/how to
expand depends on the method. And there are syntax ambiguities
("/ssh:" can be a method or a host name). And in the ftp case it must
be given to ange-ftp, IIRC.

It was a nightmare to implement, at least for me. If you find
something to simplify, I'ld really appreciate it.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: romain@orebokech.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sat, 29 Apr 2006 18:09:51 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you please point me to the right function in Tramp's sources?  I'd
> > like to understand why it is so hard to complete on host names.
> 
> Look for "tramp-completion-*". It's not only host names, but also
> methods and user names which need to be expanded. And what/how to
> expand depends on the method. And there are syntax ambiguities
> ("/ssh:" can be a method or a host name). And in the ftp case it must
> be given to ange-ftp, IIRC.

I didn't yet read the sources, so I might talk nonsense, but couldn't
we have just host-name expansion outside Tramp, and if the expanded
host name is accepted (e.g., if the user types `:'), load Tramp only
_then_?  Similarly with methods like /ssh: etc.  Would that work?

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Look for "tramp-completion-*". It's not only host names, but also
>> methods and user names which need to be expanded. And what/how to
>> expand depends on the method. And there are syntax ambiguities
>> ("/ssh:" can be a method or a host name). And in the ftp case it must
>> be given to ange-ftp, IIRC.
>
> I didn't yet read the sources, so I might talk nonsense, but couldn't
> we have just host-name expansion outside Tramp, and if the expanded
> host name is accepted (e.g., if the user types `:'), load Tramp only
> _then_?  Similarly with methods like /ssh: etc.  Would that work?

Might be possible. But still enough code to extract, because "/ssh"
can mean either method, either user name, either host name. And there
are different expansion strategies for all these cases, which must be
tried one after the other.

What might make life more complex finding the "least code to be
extracted" is the XEmacs case. Another syntax is used there. Not
relevant for this mailing list, I know, but I'ld like to keep the code
together.

I will think about your proposal.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Michael Price]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On 4/29/06, Michael Albinus <michael.albinus@gmx.de> wrote:
> What might make life more complex finding the "least code to be
> extracted" is the XEmacs case. Another syntax is used there. Not
> relevant for this mailing list, I know, but I'ld like to keep the code
> together.
>
> I will think about your proposal.

I'm just a lowly user so I don't know how much my opinion counts but
like most lowly users I'll provide it anyway :)

At work I did an informal survey of emacs users (we have quite a few)
and only one person other than myself had even heard of tramp. He
heard about it from me. If other sites are anything like mine then I'd
say that the few people that will use tramp at all won't mind having
"(require 'tramp)" in their .emacs file and will already know they
have to do so.

So why not just skip auto-loading?

Michael

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

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

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

"Michael Price" <ectospheno@gmail.com> writes:

> At work I did an informal survey of emacs users (we have quite a few)
> and only one person other than myself had even heard of tramp. He
> heard about it from me.

Even the same situation around my office. Just one other Tramp user
(but he's in the position to require and receive new features
immediately :)

> If other sites are anything like mine then I'd say that the few
> people that will use tramp at all won't mind having "(require
> 'tramp)" in their .emacs file and will already know they have to do
> so.

Maybe that was the wrong question. Tramp will be known better when it
is shipped with Emacs 22. So you should ask around who's using
ange-ftp, _this_ are potential Tramp users.

> Michael

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Miles Bader]

Michael Albinus <michael.albinus@gmx.de> writes:
> Maybe that was the wrong question. Tramp will be known better when it
> is shipped with Emacs 22. So you should ask around who's using
> ange-ftp, _this_ are potential Tramp users.

In my experience tramp is _much_ slower than even ange-ftp (in all ways,
but especially establishing connections).  I think this severely limits
its utility for general use, and potential audience.

Because of this I think the hostname (etc) completion are something that
probably don't really matter very much to most users (and I suppose may
even confuse those not expecting them -- I don't known the full list of
syntaxes which trigger them), and thus that it would be fine to enable
them only if tramp has been loaded (or enabled or whatever).

-Miles
-- 
Would you like fries with that?

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Miles Bader <miles@gnu.org> writes:

> In my experience tramp is _much_ slower than even ange-ftp (in all ways,
> but especially establishing connections).  I think this severely limits
> its utility for general use, and potential audience.

That's my fear as well. Tramp 2.1 has remarkable speedup due to
caching, but it is still too unstable for Emacs 22.

> Because of this I think the hostname (etc) completion are something that
> probably don't really matter very much to most users (and I suppose may
> even confuse those not expecting them -- I don't known the full list of
> syntaxes which trigger them), and thus that it would be fine to enable
> them only if tramp has been loaded (or enabled or whatever).

Host name completion is performed locally. So it shouldn't suffer from
Tramp's connection slowness (*).

> -Miles

Best regards, Michael.

(*): I remember the case where eager administrators generated
regularly /etc/ssh/ssh_known_hosts with _all_ hosts found in the
company's Intranet, a Fortune 500 company. Hostname completion on such
a host was a pain, until we disabled check of ssh_known_hosts.

Re: Emacs unconditionally loads tramp.el

[Miles Bader]

Michael Albinus <michael.albinus@gmx.de> writes:
>> Because of this I think the hostname (etc) completion are something that
>> probably don't really matter very much to most users
>
> Host name completion is performed locally. So it shouldn't suffer from
> Tramp's connection slowness (*).

But it's not useful to them unless they intend to use tramp.

-Miles
-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Miles Bader <miles@gnu.org> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>>> Because of this I think the hostname (etc) completion are something that
>>> probably don't really matter very much to most users
>>
>> Host name completion is performed locally. So it shouldn't suffer from
>> Tramp's connection slowness (*).
>
> But it's not useful to them unless they intend to use tramp.

They would loose ange-ftp host name completion as well, because
ange-ftp is now a Tramp backend.

As already proposed: maybe it should be customizable whether to
complete host names, or not. (Yes Eli, I'm still investigating the
alternative separating host name completion code, but it looks
difficult).

> -Miles

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>> Maybe that was the wrong question. Tramp will be known better when it
>> is shipped with Emacs 22. So you should ask around who's using
>> ange-ftp, _this_ are potential Tramp users.
>
> In my experience tramp is _much_ slower than even ange-ftp (in all
> ways, but especially establishing connections).  I think this
> severely limits its utility for general use, and potential audience.

The thing I find annoying is how slow it is for establishing a local
connection, like with /su::/etc/fstab.  Should be instantaneously,
really.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Emacs unconditionally loads tramp.el

[Drew Adams]

    The thing I find annoying is how slow it is for establishing a local
    connection...

The thing I find annoying is I've never been able to get it to work on MS
Windows - I need to be able to get to a GNU/Linux box from Emacs on Windows,
but I was never able to log in with Tramp. Kai Grossjohann spent some time
trying to help me get it to work over a year ago, but we never succeeded in
understanding the problem. I gave up. Perhaps I'll try again after the
release comes out....

Re: Emacs unconditionally loads tramp.el

[Jason Rumney]

"Drew Adams" <drew.adams@oracle.com> writes:

> The thing I find annoying is I've never been able to get it to work on MS
> Windows - I need to be able to get to a GNU/Linux box from Emacs on Windows,
> but I was never able to log in with Tramp. Kai Grossjohann spent some time
> trying to help me get it to work over a year ago, but we never succeeded in
> understanding the problem. I gave up. Perhaps I'll try again after the
> release comes out....

There are "plink" methods for working with PuTTY's command-line
terminal. I think Cygwin's ssh port expects to be run from an
interactive Cygwin bash shell, so doesn't work well under Emacs.

Re: Emacs unconditionally loads tramp.el

[Lennart Borgman]

Jason Rumney wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
>
>   
>> The thing I find annoying is I've never been able to get it to work on MS
>> Windows - I need to be able to get to a GNU/Linux box from Emacs on Windows,
>> but I was never able to log in with Tramp. Kai Grossjohann spent some time
>> trying to help me get it to work over a year ago, but we never succeeded in
>> understanding the problem. I gave up. Perhaps I'll try again after the
>> release comes out....
>>     
>
> There are "plink" methods for working with PuTTY's command-line
> terminal. I think Cygwin's ssh port expects to be run from an
> interactive Cygwin bash shell, so doesn't work well under Emacs.
>   
Are there a good description somewhere?

Re: Emacs unconditionally loads tramp.el

[Oscar Fuentes]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

>> There are "plink" methods for working with PuTTY's command-line
>> terminal. I think Cygwin's ssh port expects to be run from an
>> interactive Cygwin bash shell, so doesn't work well under Emacs.
>>   
> Are there a good description somewhere?

I found one that was good enough for me, but can't remember where.

In short, you need to install the PuTTY package and put it on your
PATH, so Emacs can run plink.exe. Second, you evaluate this:

(setq tramp-default-method "plink")

and you are done.

And yes, tramp is great but so slow that I use it less than I'll like
to.

-- 
Oscar

Re: Emacs unconditionally loads tramp.el

[Jason Rumney]

Oscar Fuentes <oscarfv@telefonica.net> writes:

> (setq tramp-default-method "plink")
>
> and you are done.

That is the default if plink is in your path. See the definition of
tramp-default-method.

Re: Emacs unconditionally loads tramp.el

[Oscar Fuentes]

Jason Rumney <jasonr@gnu.org> writes:

> Oscar Fuentes <oscarfv@telefonica.net> writes:
>
>> (setq tramp-default-method "plink")
>>
>> and you are done.
>
> That is the default if plink is in your path. See the definition of
> tramp-default-method.

I see no reference to PATH on that variable's help:

C-h v tramp-default-method

tramp-default-method is a variable defined in `tramp.el'.
Its value is "plink"

Documentation:
*Default method to use for transferring files.
See `tramp-methods' for possibilities.
Also see `tramp-default-method-alist'.

You can customize this variable.

[back]

M-x version
GNU Emacs 22.0.50.1 (i386-msvc-nt5.0.2195) of 2006-04-13 on K7

And now that we are at it, copying archives is broken (with dired
buffer showing the remote files, using `C' over a binary file, copy to
local system. Remote is NetBSD, local is WindowsXP, the file copied to
local machine has lots of bytes inserted here and there. It seems not
a line-end conversion problem). Assigning pscp (PuTTY's copy program)
to tramp-copy-program makes no difference: Tramp keeps
uuencoding-uudecoding the file.

Furthermore, Tramp seems to have problems detecting the coding system
of a remote file: loading a remote file with accented chars and saving
it again, converts the accented chars to something else, without
notice.

-- 
Oscar

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

> From: Oscar Fuentes <oscarfv@telefonica.net>
> Date: Sun, 30 Apr 2006 15:03:24 +0200
> 
> Jason Rumney <jasonr@gnu.org> writes:
> 
> > Oscar Fuentes <oscarfv@telefonica.net> writes:
> >
> >> (setq tramp-default-method "plink")
> >>
> >> and you are done.
> >
> > That is the default if plink is in your path. See the definition of
> > tramp-default-method.
> 
> I see no reference to PATH on that variable's help:

That's because the variable itself indeed does not have _any_ relation
to PATH whatsoever.  It's the way we set the _default_value_ of the
variable that looks along the PATH:

    (defcustom tramp-default-method
      (if (and (fboundp 'executable-find)
	       (executable-find "plink"))
	  "plink"
	"ssh")

>From the end-user's point of view, it is not important how Emacs
figured out it should use plink, whether by searching PATH or some
other magic.  As long as the default makes sense, the user should be
happy, since the related features will ``just work''.

So I don't think the doc string should mention PATH in this case.

(Note that Jason suggested that you look at the _definition_ of
tramp-default-method, reproduced above, not at its _doc_string_.)

> And now that we are at it, copying archives is broken (with dired
> buffer showing the remote files, using `C' over a binary file, copy to
> local system. Remote is NetBSD, local is WindowsXP, the file copied to
> local machine has lots of bytes inserted here and there. It seems not
> a line-end conversion problem). Assigning pscp (PuTTY's copy program)
> to tramp-copy-program makes no difference: Tramp keeps
> uuencoding-uudecoding the file.

Sorry, it's impossible to debug the problem using this description.
Could you please provide a short self-contained test case that can be
used to reproduce the bug?

> Furthermore, Tramp seems to have problems detecting the coding system
> of a remote file: loading a remote file with accented chars and saving
> it again, converts the accented chars to something else, without
> notice.

Again, please provide a specific recipe (in particular, what non-ASCII
characters were in the file and how were they encoded).

Thanks.

P.S. Please use a different Subject when you post the details of those
two problems, preferably as two separate messages.  TIA

RE: Emacs unconditionally loads tramp.el

[Drew Adams]

    > The thing I find annoying is I've never been able to get it
    > to work on MS Windows

    There are "plink" methods for working with PuTTY's command-line
    terminal. I think Cygwin's ssh port expects to be run from an
    interactive Cygwin bash shell, so doesn't work well under Emacs.

Yeah, I know. I think I tried plink and putty, and I will likely try them
again some rainy day.

Y'know, I don't remember ever doing anything special to get ange-ftp to
work. IIRC, I picked up vanilla Emacs and immediately accessed remote files.
Maybe I'm forgetting something, but it can't have been too difficult.

We're always talking about making things easier for newbies to use Emacs.
Well, if we expect Windows users to pick Emacs up and use it out of the box,
and if we want them to use Emacs to access remote files, and if tramp is the
default way to do that now, then I suspect we're going to be disappointed in
our expectations. Many Windows users will never experience using Emacs to
access remote files - that's my guess. And that's too bad - this Emacs
feature is much more important than most of the minutia we spend time
discussing in our attempts to make things friendlier for Emacs newbies
(menus, toolbars, fringe,...).

Here's another consideration for our globalized world: The number of people
who use MS Windows only for personal desktop stuff (mail, browser,
Word,...), and who access remote (who knows where? Texas? Bangalore?
Ireland?) GNU/Linux farm boxes for development or other stuff, is growing
fast. Nearly all of the developers at my (large) company work that way in
one way or another - likewise for many non-developers. Some people work
directly on remote G/L boxes via gateways like Tarantella and VNC, but
others prefer to work locally on Windows and access remote G/L boxes via
Emacs (ange-ftp). Some people might bother to go through the hassle of
setting up tramp to work correctly, but others will give up, I suspect.
Non-developers? Forget it....

Sorry for the rant. I just hate to see good things that work well stop
working in the name of progress. On n'arrete pas le progres...

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 29 Apr 2006 16:33:20 -0700
> 
> Y'know, I don't remember ever doing anything special to get ange-ftp to
> work. IIRC, I picked up vanilla Emacs and immediately accessed remote files.
> Maybe I'm forgetting something, but it can't have been too difficult.

What you are forgetting is how long it took until ange-ftp began to
support Windows seamlessly.  At some point, we were even distributing
an alternative ftp client, to work around bugs in the Microsoft
version.

> We're always talking about making things easier for newbies to use Emacs.
> Well, if we expect Windows users to pick Emacs up and use it out of the box,
> and if we want them to use Emacs to access remote files, and if tramp is the
> default way to do that now, then I suspect we're going to be disappointed in
> our expectations. Many Windows users will never experience using Emacs to
> access remote files - that's my guess. And that's too bad - this Emacs
> feature is much more important than most of the minutia we spend time
> discussing in our attempts to make things friendlier for Emacs newbies
> (menus, toolbars, fringe,...).

I doubt that many Windows users even consider a prospect of accessing
remote files.  But that's not an argument to avoid fixing this feature
on Windows, it's just that I don't think exaggerating its importance
is really required to convince us.

> Sorry for the rant. I just hate to see good things that work well stop
> working in the name of progress. On n'arrete pas le progres...

It's not useful to rant in this case.  Unless Tramp developers start
testing Tramp on Windows, they are under no obligation to fix Windows
problems.  Someone has to volunteer and do the job.  So either become
that person (which is the Free Software way of doing TRT), or wait
until someone else does.

RE: Emacs unconditionally loads tramp.el

[Drew Adams]

    > Y'know, I don't remember ever doing anything special to get
    > ange-ftp to work. IIRC, I picked up vanilla Emacs and immediately
    > accessed remote files.
    > Maybe I'm forgetting something, but it can't have been too difficult.

    What you are forgetting is how long it took until ange-ftp began to
    support Windows seamlessly.  At some point, we were even distributing
    an alternative ftp client, to work around bugs in the Microsoft
    version.

Sounds like a good argument for keeping ange-ftp as the Emacs default, until
tramp supports Windows (and other platforms, if appropriate) seamlessly.
That was my point.

    > We're always talking about making things easier for newbies
    > to use Emacs. Well, if we expect Windows users to pick Emacs up
    > and use it out of the box, and if we want them to use Emacs to
    > access remote files, and if tramp is the default way to do that
    > now, then I suspect we're going to be disappointed in
    > our expectations. Many Windows users will never experience
    > using Emacs to access remote files - that's my guess. And
    > that's too bad - this Emacs feature is much more important than
    > most of the minutia we spend time discussing in our attempts
    > to make things friendlier for Emacs newbies
    > (menus, toolbars, fringe,...).

    I doubt that many Windows users even consider a prospect of accessing
    remote files.

I think you are wrong about Windows users these days (and perhaps more wrong
tomorrow). Did you read the part about developers at large companies having
a Windows box in their cubicle and using remote (who knows where?) GNU/Linux
boxes for their development? I suspect that is becoming the rule rather than
the exception. Gone are the Solaris boxes in people's cubicles. Here to
stay, at least for a while, are mega-farms of cheap GNU/Linux boxes/blades.
And, at least for now, Windows is the box of choice by companies for
inter-office stuff. Perhaps tomorrow Windows will be replaced by GNU/Linux
on the desktop as well.

Of course, as I mentioned, using a remote GNU/Linux box from Windows does
not necessarily mean using Emacs locally and accessing files remotely.
Depending on the work one does (within Emacs and without), it can in many
cases be more useful to run Emacs remotely (on GNU/Linux), in order to have
Linux commands available on the remote machine within Emacs. On the other
hand, network bandwidth can sometimes argue against using non-nw Emacs
remotely. Different people have different needs in this regard.

    But that's not an argument to avoid fixing this feature
    on Windows, it's just that I don't think exaggerating its importance
    is really required to convince us.

Tramp is an important feature to fix, especially if it is to be the default.
I don't know if I exaggerate its importance. If it were not the default, so
that Emacs 22 acted like 20 and 21 out of the box (ange-ftp), then there
would be no problem.

Re: Emacs unconditionally loads tramp.el

[Michael Price]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

On 4/30/06, Drew Adams <drew.adams@oracle.com> wrote:
>     I doubt that many Windows users even consider a prospect of accessing
>     remote files.
>
> I think you are wrong about Windows users these days (and perhaps more wrong
> tomorrow). Did you read the part about developers at large companies having
> a Windows box in their cubicle and using remote (who knows where?) GNU/Linux
> boxes for their development? I suspect that is becoming the rule rather than
> the exception. Gone are the Solaris boxes in people's cubicles.

Yes, they took the Solaris box out of my cubicle about 2 years ago. It
was replaced with a Dell running GNU/Linux. Where I work only a few
people in management have Windows installed because they need it for
their PowerPoint Engineering ;)

If anyone else needs Windows for something then we connect to one
remotely. In fact, other than my manager's office I don't know the
physical location of a machine running Windows where I work.

So while I think you have a point I also think you may be overstating it a bit.

Michael

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

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

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 30 Apr 2006 07:18:55 -0700
> 
> Sounds like a good argument for keeping ange-ftp as the Emacs default, until
> tramp supports Windows (and other platforms, if appropriate) seamlessly.
> That was my point.

But Tramp does work on Windows, at least for me, with plink as the SSH
client.  Unless others say that plink, too, has problems, which aren't
seen on Posix platforms, I don't see why we should advise Windows
users to use a different setup.

(Also note that ange-ftp is now Tramp's back end, and so fetching by
FTP should work as well as it did in previous versions.  We are not
discussing FTP methods, we are discussing SSH, which is not supported
by ange-ftp at all, and so there's no alternative to Tramp there.)

>     I doubt that many Windows users even consider a prospect of accessing
>     remote files.
> 
> I think you are wrong about Windows users these days (and perhaps more wrong
> tomorrow). Did you read the part about developers at large companies having
> a Windows box in their cubicle and using remote (who knows where?) GNU/Linux
> boxes for their development?

My day job is with a large company, where almost all code developers
use Windows as their desktop OS and either Windows or GNU/Linux as the
target OS.  So I'm speaking from experience, not from theory.

> Tramp is an important feature to fix, especially if it is to be the default.

Please try plink when you have time.  It works quite well for me.

(And generally PuTTY is a wonderful package, IMHO.  I am using it for
several years, and I have yet to see a single serious bug or
misfeature.  Since I have it installed, I never looked back on the
Cygwin ports of ssh.)

RE: Emacs unconditionally loads tramp.el

[Drew Adams]

    > Sounds like a good argument for keeping ange-ftp as the Emacs
    > default, until tramp supports Windows (and other platforms,
    > if appropriate) seamlessly.

    But Tramp does work on Windows, at least for me, with plink as the SSH
    client.  Unless others say that plink, too, has problems, which aren't
    seen on Posix platforms, I don't see why we should advise Windows
    users to use a different setup.

"Seamlessly" is the operative word here. If you're right about how easy it
is, then perhaps all that's needed is a clear recipe of instructions. If
Michael A. and I are right about how hard it can be, then maybe more work
needs to be done.

    (Also note that ange-ftp is now Tramp's back end, and so fetching by
    FTP should work as well as it did in previous versions.

"Should".

    We are not discussing FTP methods,

I was also discussing FTP. As I said, I believe that I had problems even
with Tramp's (ange-) FTP (although it was over a year ago, in a convoluted
testing thread with Kai G., so I won't swear by this, as I've forgotten the
details). Perhaps Michael can confirm or correct me here about the existence
of FTP problems.

    we are discussing SSH, which is not supported
    by ange-ftp at all, and so there's no alternative to Tramp there.)

That's true. But that doesn't mean that ssh (or sshx) should be the default.
If it works well in all important cases (including local Windows to remote
GNU/Linux), then that's fine; if it doesn't, then perhaps FTP should still
be the default protocol.

    >     I doubt that many Windows users even consider a prospect
    >     of accessing remote files.
    >
    > I think you are wrong about Windows users these days (and
    > perhaps more wrong tomorrow). Did you read the part about
    > developers at large companies having a Windows box in their
    > cubicle and using remote (who knows where?) GNU/Linux
    > boxes for their development?

    My day job is with a large company, where almost all code developers
    use Windows as their desktop OS and either Windows or GNU/Linux as the
    target OS.  So I'm speaking from experience, not from theory.

Good. So we have similar experience here. In that case, why do you think
that few "Windows users even consider a prospect of accessing remote files"?

    > Tramp is an important feature to fix, especially if it is to
    > be the default.

    Please try plink when you have time.  It works quite well for me.

I will try it again when I have some time. Thx. Maybe that's the solution.

    (And generally PuTTY is a wonderful package, IMHO.  I am using it for
    several years, and I have yet to see a single serious bug or
    misfeature.  Since I have it installed, I never looked back on the
    Cygwin ports of ssh.)

Can you (or someone else) point to a simple set of instructions for using
plink and PuTTY? I still want to use Cygwin's bash shell on Windows for
other Emacs stuff, though. Thx.

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 30 Apr 2006 09:51:45 -0700
> 
>     My day job is with a large company, where almost all code developers
>     use Windows as their desktop OS and either Windows or GNU/Linux as the
>     target OS.  So I'm speaking from experience, not from theory.
> 
> Good. So we have similar experience here. In that case, why do you think
> that few "Windows users even consider a prospect of accessing remote files"?

Because I never heard anyone of them ask.  (As you can imagine, if
they have _any_ question about Emacs, the come to me.)

>     (And generally PuTTY is a wonderful package, IMHO.  I am using it for
>     several years, and I have yet to see a single serious bug or
>     misfeature.  Since I have it installed, I never looked back on the
>     Cygwin ports of ssh.)
> 
> Can you (or someone else) point to a simple set of instructions for using
> plink and PuTTY?

PuTTY comes with an online manual which is very readable and includes
detailed explanation of every option.  But in general, the defaults
work well.

After unzipping the executables, all you need to do to configure PuTTY
is to fill the few items in the session configuration dialog that pops
when you click on PuTTY's icon, and then save the session definitions--
they will be used automatically for that host thereafter.  The only
things that I change, apart of the host address and the session name,
is the location of the private key file, and sometimes the auto-login
username.  (I also play with colors, but that's just because I'm a
color customization junkie.)  That's it!

Plink is a command-line utility that is an ssh work-alike, it accepts
a somewhat different, but similar, set of command-line options.

> I still want to use Cygwin's bash shell on Windows for other Emacs
> stuff, though.

I don't think you will have any problems with PuTTY wrt Cygwin (for
example, PuTTY opens its own window, unrelated to the shell's window),
but only experience will show, since I myself don't use Cygwin at all.

RE: Emacs unconditionally loads tramp.el

[Drew Adams]

    PuTTY comes with an online manual which is very readable and includes
    detailed explanation of every option.  But in general, the defaults
    work well.
    
    After unzipping the executables, all you need to do to configure PuTTY
    is to fill the few items in the session configuration dialog that pops
    when you click on PuTTY's icon, and then save the session definitions--
    they will be used automatically for that host thereafter.  The only
    things that I change, apart of the host address and the session name,
    is the location of the private key file, and sometimes the auto-login
    username.  (I also play with colors, but that's just because I'm a
    color customization junkie.)  That's it!
    
    Plink is a command-line utility that is an ssh work-alike, it accepts
    a somewhat different, but similar, set of command-line options.
    
    I don't think you will have any problems with PuTTY wrt Cygwin (for
    example, PuTTY opens its own window, unrelated to the shell's window),
    but only experience will show, since I myself don't use Cygwin at all.
    
Thanks, Eli. I'll give it a try when I get some time.

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

"Drew Adams" <drew.adams@oracle.com> writes:

> I was also discussing FTP. As I said, I believe that I had problems even
> with Tramp's (ange-) FTP (although it was over a year ago, in a convoluted
> testing thread with Kai G., so I won't swear by this, as I've forgotten the
> details). Perhaps Michael can confirm or correct me here about the existence
> of FTP problems.

I don't know of any open ange-ftp integration problems with Tramp. A
short scan of Tramp's mailing list showed the last such report with
the date "19 Jul 2005".

Best regards, Michael.

RE: Emacs unconditionally loads tramp.el

[Drew Adams]

    I don't know of any open ange-ftp integration problems with Tramp. A
    short scan of Tramp's mailing list showed the last such report with
    the date "19 Jul 2005".
    
Good to hear. Thx.

Re: Emacs unconditionally loads tramp.el

[Stefan Monnier]

> Sorry for the rant.  I just hate to see good things that work well stop
> working in the name of progress.  On n'arrete pas le progres...

AFAIK the ftp method (which uses ange-ftp) works just as well as before.


        Stefan

RE: Emacs unconditionally loads tramp.el

[Drew Adams]

    AFAIK the ftp method (which uses ange-ftp) works just as well as before.

I had some problem with it when I tried - I'll give it another try. If it
works well then perhaps it should be the default.

Tramp & Cygwin (was: Emacs unconditionally loads tramp.el)

[Michael Albinus]

Jason Rumney <jasonr@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> The thing I find annoying is I've never been able to get it to work on MS
>> Windows - I need to be able to get to a GNU/Linux box from Emacs on Windows,
>> but I was never able to log in with Tramp. Kai Grossjohann spent some time
>> trying to help me get it to work over a year ago, but we never succeeded in
>> understanding the problem. I gave up. Perhaps I'll try again after the
>> release comes out....
>
> There are "plink" methods for working with PuTTY's command-line
> terminal. I think Cygwin's ssh port expects to be run from an
> interactive Cygwin bash shell, so doesn't work well under Emacs.

I've spent several weeks trying to make Tramp running with Cygwin's
ssh. Finally I gave up, because I didn't find a way to cooperate with
their pseudo tty. Starting Cygwin's bash first, and afterwards ssh
from there, doesn't work either, IIRC.

A "cygwinized Emacs", i.e. built under Cygwin, doesn't suffer from this
problem.

Another workaround is ssh-agent, because the only hurdle to pass is
the interactive passphrase handover to the shell starting ssh.

Note that I'm neither an expert in MS Windows nor in Cygwin, just a
very occasional user. Some people tried to help, also w/o success.

Because this belongs to the top list of "Tramp's annoyances", I would
appreciate any new idea what to do.

Best regards, Michael.

Re: Tramp & Cygwin

[Jason Rumney]

Michael Albinus <michael.albinus@gmx.de> writes:

> I've spent several weeks trying to make Tramp running with Cygwin's
> ssh. Finally I gave up, because I didn't find a way to cooperate with
> their pseudo tty. Starting Cygwin's bash first, and afterwards ssh

> Because this belongs to the top list of "Tramp's annoyances", I would
> appreciate any new idea what to do.

The manual mentions using ssh-x as a workaround.

Re: Tramp & Cygwin

[Michael Albinus]

Jason Rumney <jasonr@gnu.org> writes:

>> I've spent several weeks trying to make Tramp running with Cygwin's
>> ssh. Finally I gave up, because I didn't find a way to cooperate with
>> their pseudo tty. Starting Cygwin's bash first, and afterwards ssh
>
>> Because this belongs to the top list of "Tramp's annoyances", I would
>> appreciate any new idea what to do.
>
> The manual mentions using ssh-x as a workaround.

I guess you mean the Tramp manual.

"sshx" is like "ssh" except it uses twice the -t parameter calling
Cygwin's ssh. That is reported to have worked in the past, but with
recent Cygwin it doesn't work. Last time I've checked half a year ago,
I doubt it has changed.

Best regards, Michael.

RE: Tramp & Cygwin

[Drew Adams]

    >> I've spent several weeks trying to make Tramp running with Cygwin's
    >> ssh. Finally I gave up, because I didn't find a way to cooperate with
    >> their pseudo tty. Starting Cygwin's bash first, and afterwards ssh
    >
    >> Because this belongs to the top list of "Tramp's annoyances", I would
    >> appreciate any new idea what to do.
    >
    > The manual mentions using ssh-x as a workaround.

    I guess you mean the Tramp manual.

    "sshx" is like "ssh" except it uses twice the -t parameter calling
    Cygwin's ssh. That is reported to have worked in the past, but with
    recent Cygwin it doesn't work. Last time I've checked half a year ago,
    I doubt it has changed.

It didn't work for me either (also about a year ago).

RE: Tramp & Cygwin (was: Emacs unconditionally loads tramp.el)

[Drew Adams]

    > There are "plink" methods for working with PuTTY's command-line
    > terminal. I think Cygwin's ssh port expects to be run from an
    > interactive Cygwin bash shell, so doesn't work well under Emacs.

    I've spent several weeks trying to make Tramp running with Cygwin's
    ssh. Finally I gave up, because I didn't find a way to cooperate with
    their pseudo tty. Starting Cygwin's bash first, and afterwards ssh
    from there, doesn't work either, IIRC.

    A "cygwinized Emacs", i.e. built under Cygwin, doesn't suffer from this
    problem.

I'm in the first category (Emacs not built under Cygwin, but using Cygwin as
shell), and my experience reflects what you report (IIRC).

    Another workaround is ssh-agent, because the only hurdle to pass is
    the interactive passphrase handover to the shell starting ssh.

    Note that I'm neither an expert in MS Windows nor in Cygwin, just a
    very occasional user. Some people tried to help, also w/o success.

    Because this belongs to the top list of "Tramp's annoyances", I would
    appreciate any new idea what to do.

I appreciate your working on this. It's not a problem that Tramp is not yet
100% for Windows users; the problem I see is that it is now the Emacs
default.

Re: Tramp & Cygwin (was: Emacs unconditionally loads tramp.el)

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sun, 30 Apr 2006 08:50:49 +0200
> Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> > There are "plink" methods for working with PuTTY's command-line
> > terminal. I think Cygwin's ssh port expects to be run from an
> > interactive Cygwin bash shell, so doesn't work well under Emacs.
> 
> I've spent several weeks trying to make Tramp running with Cygwin's
> ssh. Finally I gave up, because I didn't find a way to cooperate with
> their pseudo tty. Starting Cygwin's bash first, and afterwards ssh
> from there, doesn't work either, IIRC.
> [...]
> Because this belongs to the top list of "Tramp's annoyances", I would
> appreciate any new idea what to do.

What's wrong with advising Windows users to use the plink methods,
mentioned by Jason above?  PuTTY (which Plink is part of) is free
software, and AFAIK it is the only good native Windows SSH client.
Why fight an uphill battle with Cygwin pty's when a free solution is
readily available?

My suggestion is to recommend the Cygwin ssh for users of the Cygwin
build, and plink for users of the native Windows build.

(I assume that the plink method does work for an average Windows user;
at least for me it ``just works'', I just tried with a recent CVS.  If
there are known problems with Plink, please tell what they are, or
point me to some URL where I could read about them.)

Re: Tramp & Cygwin

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> My suggestion is to recommend the Cygwin ssh for users of the Cygwin
> build, and plink for users of the native Windows build.

The Tramp documentation recommends already plink for MS Windows (node
"Default Method"), and discusses the Cygwin problems (node "Windows
setup hints"). If PuTTY is installed, plink is set as the default
method. I guess this is sufficient.

Best regards, Michael.

Re: Tramp & Cygwin

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: jasonr@gnu.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Sun, 30 Apr 2006 18:45:49 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > My suggestion is to recommend the Cygwin ssh for users of the Cygwin
> > build, and plink for users of the native Windows build.
> 
> The Tramp documentation recommends already plink for MS Windows (node
> "Default Method"), and discusses the Cygwin problems (node "Windows
> setup hints"). If PuTTY is installed, plink is set as the default
> method. I guess this is sufficient.

Yes, I think it is sufficient.

Tramp performance (was: Emacs unconditionally loads tramp.el)

[Michael Albinus]

David Kastrup <dak@gnu.org> writes:

>> In my experience tramp is _much_ slower than even ange-ftp (in all
>> ways, but especially establishing connections).  I think this
>> severely limits its utility for general use, and potential audience.
>
> The thing I find annoying is how slow it is for establishing a local
> connection, like with /su::/etc/fstab.  Should be instantaneously,
> really.

Tramp doesn't make a special handling for su(do)? methods. It runs all
the initialization commands, like being in the terra incognita of a
remote host. Changing this, could be an optimization, indeed.

There are other optimizations planned, like keeping a connection
history, in order to reduce the number of checks to be performed.

But: Tramp 2.0, as integrated in GNU Emacs 22, is in maintenance
mode. No new development shall happen there.

Tramp 2.1 has experienced several optimizations already, for example
reducing the number of commands to be sent, delaying checks until they
are needed, and file attributes caching. Some months ago I've
published comparison data, see commentary in
<http://cvs.savannah.gnu.org/viewcvs/tramp/test/tramp-time.el?rev=1.4&root=tramp&view=markup>.

It has been asked sometimes whether Tramp 2.1 could be integrated into
GNU Emacs 22. I've refused it always, because of stability, and
because there are other experimental features which need further
development before going to mainstream use.

If performance of Tramp is a critical issue for acceptance, we could
revise this decision. It should be simple to deactivate (not remove
the code of) the experimental features, because all needed defadvices
are in tramp-util.el. When this file is not present, Tramp won't use
that code.

But stability. Tramp 2.1 code basis is remarkable different from Tramp
2.0. It is used by several people, but I really don't know whether it
is a good decision to integrate it into GNU Emacs 22 so short before
the release.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: romain@orebokech.com,  emacs-devel@gnu.org
> Date: Sat, 29 Apr 2006 20:30:56 +0200
> 
> > I didn't yet read the sources, so I might talk nonsense, but couldn't
> > we have just host-name expansion outside Tramp, and if the expanded
> > host name is accepted (e.g., if the user types `:'), load Tramp only
> > _then_?  Similarly with methods like /ssh: etc.  Would that work?
> 
> Might be possible. But still enough code to extract, because "/ssh"
> can mean either method, either user name, either host name.

By ``user name'' do you mean local user name?  If so, it doesn't need
Tramp to do its job.

> I will think about your proposal.

Thanks.

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> By ``user name'' do you mean local user name?  If so, it doesn't need
> Tramp to do its job.

Nope, user names of the remote host. Extracted from "~/.ssh/config",
for example.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: romain@orebokech.com,  emacs-devel@gnu.org
> Date: Sun, 30 Apr 2006 09:00:43 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > By ``user name'' do you mean local user name?  If so, it doesn't need
> > Tramp to do its job.
> 
> Nope, user names of the remote host.

I'd say, if this is the only obstacle to avoid loading Tramp too
early, let's make this remote user-name completion an optional feature
and turn it off by default.

Re: Emacs unconditionally loads tramp.el

[Richard Stallman]

    That's not new, because it's a similar story with Emacs 21 and
    `ange-ftp-completion-hook-function'. The only difference is that
    Ange-FTP is loaded only for `file-name-completionŽ, whereas
    Tramp is loaded in more cases.

Why is Tramp loaded in more cases?  Can you get rid of them, and
arrange to load it only for file name completion?

Also, maybe it is possible to prevent loading these packages
in the specific case of just `/'.  Completion is not very
useful in that case, and that is the most likely case for someone
to type and not really want it.

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     That's not new, because it's a similar story with Emacs 21 and
>     `ange-ftp-completion-hook-function'. The only difference is that
>     Ange-FTP is loaded only for `file-name-completion´, whereas
>     Tramp is loaded in more cases.
>
> Why is Tramp loaded in more cases?  Can you get rid of them, and
> arrange to load it only for file name completion?

For GNU Emacs, it should be possible. Commentary from
`tramp-completion-file-name-handler-alist´ (I haven't checked further
yet):

;; Handlers for partial tramp file names. For GNU Emacs just
;; `file-name-all-completions' is needed. The other ones are necessary
;; for XEmacs.

But this problem has reached XEmacs mailing lists as well. I fear a
general solution is needed.

> Also, maybe it is possible to prevent loading these packages
> in the specific case of just `/'.  Completion is not very
> useful in that case, and that is the most likely case for someone
> to type and not really want it.

That would be simple:

(defconst tramp-completion-file-name-regexp-unified "^/[^/:][^/]*$")

A user would need to type at least one additional character after the
leading "/" in order to get Tramp loaded. But this still will happen
without typing <TAB> or so, just due to `expand-file-name´.

Meanwhile, I doubt whether it is worth the trouble. We could revert
the patch, and would fall back to the following scenario:

- After starting Emacs, there is no hostname completion for remote file
  names.
- After using the first remote file name, Tramp is loaded, and
  hostname completion is active.
- If a user wants to use hostname completion immediately after
  starting Emacs, a simple (require 'tramp) in .emacs is sufficient.

This must be documented. It seems to be more accepted (see Eli's
message on this subject). Shall we go this direction?

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Eli Zaretskii]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@iro.umontreal.ca,  romain@orebokech.com,  emacs-devel@gnu.org,  eliz@gnu.org
> Date: Fri, 28 Apr 2006 21:58:09 +0200
> 
> ;; Handlers for partial tramp file names. For GNU Emacs just
> ;; `file-name-all-completions' is needed. The other ones are necessary
> ;; for XEmacs.
> 
> But this problem has reached XEmacs mailing lists as well. I fear a
> general solution is needed.

If a general solution is possible, it's preferable.  But of not, it's
better not to punish both platforms, even if that means the default
behavior is slightly different.

> (defconst tramp-completion-file-name-regexp-unified "^/[^/:][^/]*$")
> 
> A user would need to type at least one additional character after the
> leading "/" in order to get Tramp loaded. But this still will happen
> without typing <TAB> or so, just due to `expand-file-name´.

I don't think this solves the problem, at least not mine: I rarely
type TAB right after the first slash.

> Meanwhile, I doubt whether it is worth the trouble. We could revert
> the patch, and would fall back to the following scenario:
> 
> - After starting Emacs, there is no hostname completion for remote file
>   names.
> - After using the first remote file name, Tramp is loaded, and
>   hostname completion is active.
> - If a user wants to use hostname completion immediately after
>   starting Emacs, a simple (require 'tramp) in .emacs is sufficient.

If we go this way, I think it's better to have an explicit option
rather that ask users to load Tramp.  That's because, no matter how
well we document this, it's a counter-intuitive kludge.  It is also
not nice to have behavior changed when a package is loaded that has no
clear relation to the behavior we are discussing (i.e. host name
completion).

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> If we go this way, I think it's better to have an explicit option
> rather that ask users to load Tramp.  That's because, no matter how
> well we document this, it's a counter-intuitive kludge.  It is also
> not nice to have behavior changed when a package is loaded that has no
> clear relation to the behavior we are discussing (i.e. host name
> completion).

I've installed a patch in Emacs CVS which activates hostname
completion only when partial-completion-mode is enabled. In its
current definition, partial-completion-mode isn't related to remote
files, but it was the best place I could imagine to use.

Introducing a new customer option instead is still an alternative, and
I'm open to this when there is such a request.

Extracting hostname completion code from Tramp still seems to be too
complex to me. Maybe we can do it later with Tramp 2.1; performing it
now would destabilize Tramp I fear.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Richard Stallman]

    A user would need to type at least one additional character after the
    leading "/" in order to get Tramp loaded. But this still will happen
    without typing <TAB> or so, just due to `expand-file-nameŽ.

(expand-file-name "/") should NOT load tramp!

I just found that this problem was due to XEmacs compatibility code.
So I deleted that code.  I won't delete XEmacs compatibility code
merely because it is XEmacs compatibility code; but I won't let
a bug remain in Emacs for the sake of XEmacs.


I also noticed this:

    ; These values conform to `file-attributes' from XEmacs 21.2.
    ; Emacs and other tools not checked.
    (defconst tramp-file-mode-type-map

What exactly hasn't been checked here?

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> I just found that this problem was due to XEmacs compatibility code.
> So I deleted that code.  I won't delete XEmacs compatibility code
> merely because it is XEmacs compatibility code; but I won't let
> a bug remain in Emacs for the sake of XEmacs.

Could we agree on this?

magdalene:~/src/emacs/lisp/net> cvs diff tramp.el
Index: tramp.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/net/tramp.el,v
retrieving revision 1.95
diff -u -r1.95 tramp.el
--- tramp.el    29 Apr 2006 15:58:31 -0000      1.95
+++ tramp.el    29 Apr 2006 19:50:57 -0000
@@ -1931,9 +1931,14 @@
 ;; Handlers for partial tramp file names.  For Emacs just
 ;; `file-name-all-completions' is needed.
 (defconst tramp-completion-file-name-handler-alist
-  '(
-    (file-name-all-completions . tramp-completion-handle-file-name-all-completions)
-    (file-name-completion . tramp-completion-handle-file-name-completion))
+  (append
+   '((file-name-all-completions . tramp-completion-handle-file-name-all-completions)
+     (file-name-completion . tramp-completion-handle-file-name-completion))
+   (when (featurep 'xemacs)
+     '((file-name-directory . tramp-completion-handle-file-name-directory)
+       (file-name-nondirectory . tramp-completion-handle-file-name-nondirectory)
+       (file-exists-p . tramp-completion-handle-file-exists-p)
+       (expand-file-name . tramp-completion-handle-expand-file-name))))
   "Alist of completion handler functions.
 Used for file names matching `tramp-file-name-regexp'. Operations not
 mentioned here will be handled by `tramp-file-name-handler-alist' or the

> I also noticed this:
>
>     ; These values conform to `file-attributes' from XEmacs 21.2.
>     ; Emacs and other tools not checked.
>     (defconst tramp-file-mode-type-map
>
> What exactly hasn't been checked here?

Don't know, it was written before I've entered the Tramp team. I'll
check.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Richard Stallman]

I don't mind if you install some XEmacs compatibility code,
just don't let it cause bad results on Emacs.

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> I also noticed this:
>
>     ; These values conform to `file-attributes' from XEmacs 21.2.
>     ; Emacs and other tools not checked.
>     (defconst tramp-file-mode-type-map
>
> What exactly hasn't been checked here?

It's a comment from the time before I've entered the Tramp
team. Anyway, the author checked the correctness of the following
definition with his local copy of XEmacs 21.2. Since it is proven for
years that the definition is correct for any Emacs flavor, I've
removed the comment.

Best regards, Michael.

Re: Emacs unconditionally loads tramp.el

[Richard Stallman]

    That's right. It is due to `tramp-register-file-name-handlers' in
    `emacs-startup-hook', which is an autoloaded function. But Tramp would
    be loaded anyway when one tries to complete a filename in the
    minibuffer, because the intention of my change is to provide
    method/username/hostname completion for remote files. "C-x C-f / <TAB>"
    would be sufficient to load Tramp.

We need to talk about this.  I don't want completion to load Tramp
in common cases that don't really involve use of Tramp.

Re: Emacs unconditionally loads tramp.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     That's right. It is due to `tramp-register-file-name-handlers' in
>     `emacs-startup-hook', which is an autoloaded function. But Tramp would
>     be loaded anyway when one tries to complete a filename in the
>     minibuffer, because the intention of my change is to provide
>     method/username/hostname completion for remote files. "C-x C-f / <TAB>"
>     would be sufficient to load Tramp.
>
> We need to talk about this.  I don't want completion to load Tramp
> in common cases that don't really involve use of Tramp.

I see the point. Maybe it should be customizable somehow, whether the
hostname completion regexp is active.

OTOH, when ange-ftp was hooked into file-name-handler-alist, it was
exactly that behaviour. "C-x C-f / <TAB>" started hostname completion.
See respective (not active) code from ange-ftp:

;;-;;; This regexp recognizes absolute filenames with only one component,
;;-;;; for the sake of hostname completion.
;;-;;;###autoload
;;-(or (assoc "^/[^/:]*\\'" file-name-handler-alist)
;;-    (setq file-name-handler-alist
;;-	  (cons '("^/[^/:]*\\'" . ange-ftp-completion-hook-function)
;;-		file-name-handler-alist)))

Best regards, Michael.