From: Robert Thorpe <rt@robertthorpeconsulting.com>
To: Andrey Lisin <andrey.lisin@gmail.com>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Why do we need a number of different terminal modes in Emacs?
Date: Sun, 01 Feb 2015 13:37:11 +0000 [thread overview]
Message-ID: <87egq9sqgo.fsf@robertthorpeconsulting.com> (raw)
In-Reply-To: <m2y4oikszi.fsf@gmail.com> (message from Andrey Lisin on Sun, 01 Feb 2015 13:09:53 +0600)
Andrey Lisin <andrey.lisin@gmail.com> writes:
> Hi everyone,
>
> could anyone explain me why do we need several of terminal
> implementations inside Emacs? Shell, eshell, term, ansi-term... And as
> far as I noticed they all suck one way or another. For example, shell
> cannot complete commands when you ssh to remote server inside it. Eshell
> tragically cannot do a very simple thing - source a bash script. Really,
> try to run `. some_script.sh' or `source some_script.sh' inside eshell.
>
> So, am I right and we need them all just because one solves restrictions
> of the others and others do the same thing for the one? Why then not
> just to write some standard terminal implementation, that will just
> works? Does it have something with cross-platform nature of Emacs? Or,
> maybe I'm doing something wrong and all this stuff makes sense? Thank
> you.
I'll explain the trickiness. Shell-mode works in an Emacs-like manner.
It hooks to an external shell, such as bash, ksh or tcsh. It transfers
*lines* to the shell. It has to work this way, since the line is edited by
Emacs editing commands. Emacs editing commands work exactly as they do
elsewhere in Emacs. For example, if you do C-a in tcsh or sh it will
bring you to the beginning of the line, that's not a feature of those
shells. You can define keymaps for any key you like.
The shell-mode system can only work for programs with line-orientated
input. A program that responds to keys one at a time can't be handled
this way. Shell modes doesn't even try to do this, or to deal with
programs that have text-based GUIs, like "top" or curses programs. Type
"top" in shell and see what happens. Notice you have to type "q RET" to
exit, not just "q".
So, we have the terminal modes: ansi-term and term. These emulate
*terminals* imperfectly, and a shell runs under that terminal. These
have two modes, line mode and character mode. In line-mode they behave
like shell mode as I described above. In character mode they relay
characters one-at-a-time to the inferior program. You switch between
the two modes with C-c C-j and C-c C-k. Emacs only catches a few keys,
C-x, C-c, C-num and a few other without passing them through (see C-h m
in term-mode). You can run programs with text-based GUIs like "top" and
"emacs -nw" in terms.
For example. Go into term mode using bash. Type some stuff in and
press M-b & M-f to move across words. This works in either character
mode (C-c C-k) or line mode (C-c C-k). It works in line mode because
those are Emacs keybindings and it works in character mode because
they're bash keybindings. Now, run another shell like dash. Try M-b &
M-f there. They will work in line mode but fail in character mode.
There is little difference between term and ansi-term. In the past only
ansi-term had colours, now both do. The prefix key is C-c in term and
C-x in ansi-term.
Eshell is a completely different thing. It's a shell written in Emacs
Lisp. The idea of it is that you can write lisp at the command prompt
as well as calling shell programs. For example you can write (+ 2 3) at
the eshell prompt and it will return 5. Eshell can't source bash scripts
because bash is nowhere in sight here. Like shell-mode it doesn't
emulate a terminal or have a character mode, so you can't use it with
the programs that need that.
For your use I think term in line-mode would be best, switching to
character mode when necessary.
BR,
Robert Thorpe
next prev parent reply other threads:[~2015-02-01 13:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-01 7:09 Why do we need a number of different terminal modes in Emacs? Andrey Lisin
2015-02-01 13:37 ` Robert Thorpe [this message]
2015-02-01 14:10 ` Andrey Lisin
2015-02-02 15:55 ` zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?) Karl Voit
2015-02-03 0:42 ` Robert Thorpe
2015-02-07 11:50 ` Karl Voit
2015-02-07 20:51 ` Robert Thorpe
2015-02-09 13:13 ` Karl Voit
2015-02-09 18:57 ` Bob Proulx
2015-02-10 3:21 ` Robert Thorpe
2015-02-10 14:03 ` Karl Voit
[not found] ` <mailman.19583.1423488667.1147.help-gnu-emacs@gnu.org>
2015-02-10 0:22 ` Emanuel Berg
2015-02-10 11:00 ` zsh outside of Emacs Tory S. Anderson
[not found] ` <mailman.19666.1423566011.1147.help-gnu-emacs@gnu.org>
2015-02-11 0:58 ` gnuplot (was: Re: zsh outside of Emacs) Emanuel Berg
2015-02-11 3:28 ` Robert Thorpe
[not found] ` <mailman.19445.1423309865.1147.help-gnu-emacs@gnu.org>
2015-02-07 21:16 ` zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?) Emanuel Berg
2015-02-01 15:00 ` Why do we need a number of different terminal modes in Emacs? Marcin Borkowski
[not found] <mailman.19088.1422774606.1147.help-gnu-emacs@gnu.org>
2015-02-01 10:37 ` Pascal J. Bourguignon
2015-02-01 11:10 ` Andrey Lisin
2015-02-01 11:24 ` Andrey Lisin
[not found] ` <mailman.19095.1422789865.1147.help-gnu-emacs@gnu.org>
2015-02-01 15:09 ` Dan Espen
2015-02-01 22:16 ` Robert Thorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87egq9sqgo.fsf@robertthorpeconsulting.com \
--to=rt@robertthorpeconsulting.com \
--cc=andrey.lisin@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).