Re: realgud now in elpa

[Eli Zaretskii <eliz@gnu.org>]

> From: Rocky Bernstein <rocky@gnu.org>
> Date: Sat, 30 Jul 2016 10:56:33 -0400
> Cc: clement.pitclaudel@live.com
> 
> 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
users.

Here are the comments:

1. The package needs additional dependencies to start working:

   load-relative
   loc-changes
   list-utils

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
   executable.

   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
   realgud.

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
   ^Z^Zd:\foo\bar\src\emacs.c:674:19557:beg:0x11517b0
   (gdb) n
   ^Z^Zd:\foo\bar\src\emacs.c:675:19578:beg:0x11517b7
   (gdb)

   I don't think seeing these annotations is useful; gud.el doesn't
   show them.

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
   command correctly.

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
   error message.

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.