[Top][All Lists]

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

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

From: Rocky Bernstein
Subject: Re: Grand Unified Debugger Rewrite's process buffer: comint, eterm or eshell?
Date: Sun, 1 Nov 2009 11:08:53 -0400

Thanks for the information.

I should have mentioned that although in the long term there are some who feel that one will never switch to this buffer and work with the debugger in command-line mode, in the short term that will have to be the case.

So in the long term having highlighting prompts is probably not as important as having a good API to interface to from Emacs Lisp. But that said, term.el doesn't have an output filter function while comint.el does.

I originally started an output filter function for term.el by calling set-process-filter on the term buffer, but based in this info have switched to comint instead.

Down the line if it is really important to support term.el, I think that can be done. For example the tracker mode currently works for programs run from eshell and from shell (but not term for the reason mentioned).

Again, thanks for the info.

On Sat, Oct 31, 2009 at 1:51 AM, Miles Bader <address@hidden> wrote:
Rocky Bernstein <address@hidden> 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.


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

reply via email to

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