Re: Grand Unified Debugger Rewrite's process buffer: comint, eterm or eshell?

[Miles Bader <miles@gnu.org>]

Rocky Bernstein <rocky@gnu.org> writes:
> 1. I can stick with comint.el. It seems the most creaky.
> 2. term.el is pretty cool, but it doesn't provide a hook to run when
> 3. eshell.el. It also seems pretty cool too. However its focus seems

One thing is that people are used to using comint, and are used to using
its features (both interactive and customization) with both shells and
sub-modes such as gud-mode.  While both term.el and eshell are
well-intentioned, they both started development a long time ago when
comint was less capable, and have in general not picked up new features
added to comint.  So... you can't really think of them as being strict
functional supersets of comint, they're more like... different branches
in the same tree.

E.g., one thing I've worked on a lot in comint has been prompt handling,
and as a result, comint handles prompts nicely (with highlighting and
"prompt avoidance" etc), whereas term.el doesn't (and eshell kinda
does, but not so well, and only in some cases).

Eshell seems a very different thing than either comint or term.el.  The
latter two essentially talk to an I/O stream attached to a subprocess,
and work by interpreting the output.  Eshell, on the other hand, issues
individual commands separately, and so can maintain far finer control
_between_ subcommands, but as a result tends to be not so good as long
as the subprocess itself still has control.  [As an example, start
eshell, and then type "/bin/sh" to start a subshell.  Note that although
you get shell prompts etc, everything suddenly seems "dumb" -- whereas
if you start a subshell in a comint shell, it basically seems exactly
the same as the parent shell.]

I think that eshell probably isn't appropriate for gdb for that reason.

-Miles

-- 
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.