emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recommend move eshell/su and eshell/sudo to em-tramp.el


From: Michael Albinus
Subject: Re: Recommend move eshell/su and eshell/sudo to em-tramp.el
Date: Fri, 29 Jun 2012 11:45:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

"John Wiegley" <address@hidden> writes:

> Something I've noticed after moving to Emacs 24 is that using "sudo" in Eshell
> has become an awful experience:
>
>     - It's *much* slower than *sudo (by orders of magnitude)
>     - It doesn't show any output until the command is done
>     - It locks up Emacs until the command is done

There is much room for improvement, no question. If I have time, I'll
look on it next days.

> I find this behavior distasteful, since sudo is such a common command for
> users of Eshell to use.  It was added in 2009 by the Tramp author:
>
>     2009-11-27  Michael Albinus  <address@hidden>
>
>            * eshell/em-unix.el (eshell/su, eshell/sudo): New defuns,
>            providing a Tramp related implementation of "su" and "sudo".
>            (eshell-unix-initialize): Add "su" and "sudo".
>
> I appreciate what these two functions are trying to accomplish, but they
> should not have been made the default.

They aren't the default, if default-directory is local. And if the
default directory is remote, they do exactly what is intended: run the
command on that remote machine. It isn't only su or sudo, this is true
for all other commands as well.

> I recommend moving them out of em-unix.el and into a new module,
> em-tramp.el, which is OFF by default.  Users who prefer to use Tramp
> for everything can turn it on, and a note to that effect should be
> added to the Tramp manual.

If we do this (I'm not convinced yet), it shall be called em-remote.el
or so. Tramp is just an example for an implementation of process-file
and start-file-process; there could be other file name handlers which
will provide an own implementation.

> John

Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]