Re: realgud now in elpa

[Rocky Bernstein]

Thanks for trying out the package and your detailed comments. As you probably know as an emacs maintainer, feedback and bug reporting is very helpful.

Although I'll make some general comments here and some more specific ones below inline, bug reporting for ELPA packages isn't something that generally goes on in emacs-devel. Issue tracking for this package is currently done in  https://github.com/realgud/realgud/issues . If you look there, some of the concerns you raise, have already been reported.

I'm sure  I don't have to tell you as an emacs maintainer the value of separating out bugs into individual reports so that they can be tracked separately. So I invite you to look at the list of issues and report those that haven't been mentioned raised or add comments to the ones that have where appropriate.

Other comments in line.

On Sun, Jul 31, 2016 at 2:50 PM, Eli Zaretskii <address@hidden> wrote:

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

It must have been from the git repo, since last I tried installing via ELPA, as I reported, subdirectories were missing. 

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.

I don't take it as discouragement. But please use the issue tracker for reasons mentioned above.

Here are the comments:

1. The package needs additional dependencies to start working:

   load-relative
   loc-changes
   list-utils

The dependency on list-utils has been dropped. You probably need to update your elpa git repo if you are still seeing this. As for load-relative and loc-changes, they do work. (load-relative has problems inside of a spacemacs installer, but I doubt that's what you are running into.)

So the above comment is too vague to be actionable. Please make it more precise and add it as an issue in the github tracker.

2. "M-x realgud:gdb RET" fails to propose emacs.exe (or any other
   executable file) as the file to debug,

It is possible that on Microsoft Windows environments it will fail to find exe's. Suggest a patch. I'm not sure however that it is a bug not to propose a file to debug since gdb can work by taking a process number instead of a program name. 

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.

File an issue on this. 

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

Probably one of the many bugs that needs to be track down. 

 

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.

 

I've looked at gdb-mi and how it handles windows and it feels to me a bit unmodular. But by all means if you understand how to extract that code, please submit a pull request with the changes or whatever the corresponding thing in savannah is.

 

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.

Integrating the MI interface into realgud may require some thought. As with other things feel free to submit patches to move that code over, 

In general, right now gdb support just isn't as good as gdb-mi. So if your debugger needs are simply for gdb as it appears, then stick to gdb-mi. 

And/or dig in and help improve gdb support.

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.

Probably a bug. Submit an issue.

 

6. The support for displaying values of variables in tooltips requires
   a click; the original GUD didn't, which IMO was more convenient.

 

For gdb this makes sense. However in most cases it was disabled for a reason. In other languages you are running eval and that can be state changing,

So for other languages this will probably stay as is. Maybe there can be a flag that says automatically run eval.

And given that, there is now the question of whether things should be consistent in gdb with the way other things work. I'm kind of ambivalent. If someone proposes a patch for realgud's gdb we'll probably try it the other way.

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.

I think this bug has been reported,. 

 

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.

Not sure that erasing part of a GDB prompt is that bad. Open an issue so this could be discussed separately.

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.

Ah - this is a common comment. 

When rms wrote emacs he designed it with it being "extensible" and "modular". In the description of realgud I in fact use the term "modular" too and was very much thinking of rms's description of emacs. I'll also probably add the word "extensible". 

"Extensible" here I think meant not that rms was going to extend it in all the ways that others were going to imagine. But that could be extended, especially by others if they so choose, Since the program is modular, it is straightforward to extend. 

Although I was aware that there is a debugger for GNU Make, I was not previously aware that there was one for GNU awk. But that's okay, I just learned this and this is good to know.

I took a look at it and it seems very straightforward to add. It probably could be added in a couple of hours or so.

However, I'm not a big user of GNU awk and it is not something I will probably be able to  undertake or support. 

But as I said, this question though comes up a lot. And so I have written instructions for how to add a new debugger. These instructions are a little github centric, but I'm sure you will have no trouble adapting them savannah's git.

Supporting debugging ELisp is something I would like to see happen and may eventually do. But it is something that will probably require a bit of thought.

10.An attempt to get a backtrace hangs Emacs; C-g gets out of the
   hang, but doesn't display anything.

Another bug I think already reported for other debuggers, but not on gdb, Is probably related to MS Windows interaction. 

Thanks again for working on this.

Thanks for your feedback.