[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: realgud now in elpa
Re: realgud now in elpa
Sun, 31 Jul 2016 21:50:25 +0300
> From: Rocky Bernstein <address@hidden>
> Date: Sat, 30 Jul 2016 10:56:33 -0400
> Cc: address@hidden
> Folks -
> With the last of the copyright assignments changed, a possible replacement
> for "gud.el" called "realgud.el" is
> now in elpa.
> I make lots of mistakes (which is why I work on debuggers), so no doubt there
> will need to be some
> adjustment. Feel free to dig in or let me know.
Thanks. It's good to see that the debugger front-end gets worked on
again, after a long pause.
I've played with the package, and the below are my comments. I hope
you will not take it as any discouragement of your efforts; rather the
opposite: we the maintainers value anyone who is willing to step up
and contribute real work. Please accept these as ways to further
improve your package, so it achieves the maximum benefit for our
Here are the comments:
1. The package needs additional dependencies to start working:
2. "M-x realgud:gdb RET" fails to propose emacs.exe (or any other
executable file) as the file to debug, after a longish delay
(probably used for looking up files in the current directory).
When I type "./emacs.exe RET", it says:
emacs.exe is large (66.6M), really open? (y or n)
This prompt was unexpected, since Emacs doesn't need to visit the
Answering "y" causes another unexpected message in the echo area:
Debugger track mode is already enabled.
Why "already"? And why is it important for me to know that mode is
already active? (The message sounds as if I made some mistake.)
3. The UI is the old GUD style, without the additional windows
available with gdb-mi.el, and features available in those windows.
I think a modern debugger UI should be similar to what other IDEs
offer, and gdb-mi is much closer to that ideal than either GUD or
4. The GDB interface used is annotations, which is deprecated by the
GDB developers, not the more modern MI. Moreover, the annotations
emitted by GDB are actually shown in the command buffer. Example:
Temporary breakpoint 3, main (argc=2, argv=0xa412f8) at emacs.c:674
I don't think seeing these annotations is useful; gud.el doesn't
5. Completion seems to always complete on file names, even when typing
parts of GDB commands that have nothing to do with file names.
E.g., typing TAB at (gdb) prompt mostly says "No match", but if you
type "sea TAB", it will complete to search.c (when the default
directory is the Emacs src directory). My guess is that the
completion is either not delegated to GDB, but instead attempted by
the package itself, or the completion provided by GDB is used
incorrectly. Because GDB has no problems with completing each
6. The support for displaying values of variables in tooltips requires
a click; the original GUD didn't, which IMO was more convenient.
7. Clicking on the fringe sets a breakpoint and displays that fact on
the fringe; a second click deletes the breakpoint, but the fringe
marker is not removed. Additional clicks on that marker cause a
"delete N" command to be again sent to GDB, which responds with an
8. Clicking the "Next" button on the tool bar leaves a fading trace of
the previous stop points (arrow1, arrow2, etc.), which is nice.
However, the same trace is displayed in the command buffer, where I
think it's unnecessary and confusing. In fact, for the arrow to be
shown in the command buffer is something I don't expect. On a TTY
frame, showing these arrows in the command buffer overwrites the
GDB prompts and other information in the 1st 2 columns of each line
where an arrow is displayed.
9. I hoped this will support debugging ELisp programs, but it doesn't,
which I think is unfortunate. One other omission I spotted is the
GNU Awk's built-in debugger.
10.An attempt to get a backtrace hangs Emacs; C-g gets out of the
hang, but doesn't display anything.
Thanks again for working on this.