Re: realgud now in elpa

[Rocky Bernstein <rocky@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 9180 bytes --]

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 <eliz@gnu.org> wrote:

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



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
<https://github.com/rocky/remake>, 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
<https://github.com/realgud/realgud/wiki/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.

[-- Attachment #2: Type: text/html, Size: 13867 bytes --]