gud.el organization and adding debuggers

[R. Bernstein]

Recently I've been working on debuggers for GNU make (mdb) and
extending the Python debugger (pydb). And of course I would like
these to be work well from inside GNU Emacs (via gud).

Well, it seems I went through this once before with the bash debugger:
The procedure if I recall correctly was that I cut-and-past a new
section of gud.el. The cut-and-past for a debugger portion seems to be
the first Emacs Lisp statement that starts: (defvar gud-xxx-history
nil) - and the comments before.

And then you submit a patch; perhaps it's accepted; and then wait
maybe 3 years for the next release to come out. :-)

Hmmm. In foundling projects like these debugger projects, releases
occur a bit quicker and I think it is important that they do. To get
the word out, probably one needs to submit some standalone Emacs Lisp
code with the package.

Not really a problem. You basically add a (require 'gud) and
cut and past the code that starts (devar gud-xxx-history ... 

Well, almost. There's this declaration of gud-menu-map towards the top
of gud.el and that lists capabilities for all of the debuggers it
knows about. In order to get capabilities for the menu items that gud
doesn't think your debugger will have (like "up") and disable features
that gud thinks your debugger *must* have (like "stepi"??), one needs
to do something additional. What I've been doing is including in the
function which runs the debugger (e.g. bashdb, mdb or pydb) a
define-key function like this:

  (define-key gud-menu-map [up]        '("Up Stack" . gud-up))

I'm not a GNU-Emacs wizard, so no doubt someone may or should correct
me if this is not the most linguistically pure Lisp thing to do. But
it does seem to set the menu correctly for those specific debugger
buffers while not interfering with other debugger buffers.

Now let's come back to gud.el and how it is organized. It would focus
the attention of those would-be cut-and-past debugger extenders like
myself if say all those debuggers were broken out into their own file
and possibly pulled in by require's (or something similar - again, I"m
not a wizard). Seems to be just a little cleaner and more modular. If
one needs to remove a debugger (e.g. someone forgot to submit GPL
papers), you remove the "require" and the associated file.

So in this scenario to add a new debugger you copy a *file* rather
than a section of this file and *forget* to modify that
gud-menu-map. And along with this, I guess I'm also suggesting that
instead of listing all of the debugger capabilities in the
easy-mmode-defmap gud-menu-map, the capabilities would be added in the
individual debuggers.

- - - -

Some other miscellaneous remarks. I note that in gud.el CVS more
gud-menu-map items have been added. Excellent! One of them is "run",
but I note that most of the time it is nil. I'm assuming "run" means
the gdb "run" command, which I think would better be called "restart".

If gud's "run" is supposed to indicate something else, then given it's
not used all that much even in gud, then I'd suggest renaming it to
mean "restart" or adding a "restart" menu item. bashdb for example has
such a command, so does gdb, perldb, mdb, and pydb. In other words,
restarting is a pretty common thing you might want to do.

The other menu items that I've added to my debuggers is 

* something to show a stack trace -- gud-where with key T which is
  what perldb, mdb, pydb and bashdb use.

* something to toggle line tracing

- - - 

"local-set-key [menu-bar debug up]" is used in the various
debuggers. On my GNU Emacs 21.4.1 (GNU/Linux) with X Windows, I am not
aware of any evidence of menu-bar in the display. Where is it?

Thanks.