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

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

[rocky]

I have started to rewrite gud from the ground up.

For the process buffer I have 3 choices.

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
output is produced and this is something I need. I use it both in
comint.el and eshell.el in "shell tracker" (think pdb-track) mode. So
this leads to the last choice ...

3. eshell.el. It also seems pretty cool too. However its focus seems
to be more as a command shell rather than a process buffer manager
interacting via elisp to a debugger front-end. This mismatch in goals
manifests itself in little things like the ability to set the name of
the buffer initially, starting the shell with a specific debugger
invocation, customizing the banner shown on entry, avoiding the myriad
of key bindings that are not applicable here. Although little things
each easly addressed, I think they are manifestations of the larger
issue may keep cropping up if I go down this path.

So right now, my take is to add a output filter hook to term.el. But
I'd be interested and grateful in thoughts and suggestions.

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

[Dave Love]

rocky <rocky@gnu.org> writes:

> I have started to rewrite gud from the ground up.

Why, exactly?

> For the process buffer I have 3 choices.
>
> 1. I can stick with comint.el. It seems the most creaky.

`Creaky' how?  The whole idea of comint is to be a general way to run
sub-processes like debuggers, although there should be another layer to
abstract things like inferior programming interpreters.  What's wrong
with it for that?

> I use it both in
> comint.el and eshell.el in "shell tracker" (think pdb-track) mode. 

I implemented a prototype gud-minor-mode long ago for that sort of
thing, as alluded to in python.el if I recall correctly.  It's
straightforward but can't be a simple add-on to GUD, so wasn't going to
be useful.  The pdbtrack stuff is a mistake, apparently from a
mono-lingual programming culture, and it's unfortunate it's been
installed in Emacs, making it harder to do the right thing.

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

[rocky]

On Nov 1, 4:30 pm, Dave Love <f...@domain.invalid> wrote:
> rocky <ro...@gnu.org> writes:
> > I have started to rewrite gud from the ground up.
>
> Why, exactly?
>
> > For the process buffer I have 3 choices.
>
> > 1. I can stick with comint.el. It seems the most creaky.
>
> `Creaky' how?  The whole idea of comint is to be a general way to run
> sub-processes like debuggers, although there should be another layer to
> abstract things like inferior programming interpreters.  What's wrong
> with it for that?

That comment was based on writing both a output filter hook for comint
and then one for eshell. The comint hook is passed a string with the
text to do the insertion, while the eshell hook you pass nothing. Why
nothing? Experience I guess seems to show that it's easier just to
work with the process buffer assuming the there have been marks set.
eshell and term have such marks {term,eshell}-last-input-{start,end}
while  comint seems to have only gotten this recently (Mar '08). I
guess the last time I looked this wasn't there.


>
> > I use it both in
> > comint.el and eshell.el in "shell tracker" (think pdb-track) mode.
>
> I implemented a prototype gud-minor-mode long ago for that sort of
> thing, as alluded to in python.el if I recall correctly.  It's
> straightforward but can't be a simple add-on to GUD, so wasn't going to
> be useful.  The pdbtrack stuff is a mistake,

If by "a mistake" you mean something other than it is language
specific, I'd be interested to learn in what ways you think it a
mistake.

> apparently from a
> mono-lingual programming culture, and it's unfortunate it's been
> installed in Emacs, making it harder to do the right thing.

A multi-lingual track mode is working in http://github.com/rocky/emacs-dbgr
and
it has been configured for bashdb, kshdb, zshdb, rdebug, rbdbgr, pydb,
pydbgr and remake which is enough for my needs.

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

[Tom Tromey]

>>>>> "Dave" == Dave Love <fx@domain.invalid> writes:

Dave> I implemented a prototype gud-minor-mode long ago for that sort of
Dave> thing, as alluded to in python.el if I recall correctly.

This sounds like an excellent idea.

Tom