From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Rocky Bernstein Newsgroups: gmane.emacs.devel Subject: Re: realgud now in elpa Date: Sun, 31 Jul 2016 19:58:11 -0400 Message-ID: References: <831t29prpq.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c11ab089598dd0538f741c4 X-Trace: blaine.gmane.org 1470009528 1223 80.91.229.8 (31 Jul 2016 23:58:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2016 23:58:48 +0000 (UTC) Cc: clement.pitclaudel@live.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 01 01:58:33 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bU0cq-0000Gs-6U for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2016 01:58:32 +0200 Original-Received: from localhost ([::1]:41191 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bU0cm-0006ky-6m for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2016 19:58:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bU0ce-0006kn-AY for emacs-devel@gnu.org; Sun, 31 Jul 2016 19:58:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bU0cb-0004lh-GJ for emacs-devel@gnu.org; Sun, 31 Jul 2016 19:58:20 -0400 Original-Received: from mail-ua0-x242.google.com ([2607:f8b0:400c:c08::242]:35874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bU0cW-0004lI-RV; Sun, 31 Jul 2016 19:58:13 -0400 Original-Received: by mail-ua0-x242.google.com with SMTP id m60so5840868uam.3; Sun, 31 Jul 2016 16:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RJqMhQChawsyvn1lusI/GblL/4qcbpXoYzXN+67HPwc=; b=rrrIMGBfRz2dmJeudescuAV0i1I2kLNjIufiW0y04bbqvuRjRh/J+0uQZ+GOFwyt1M Et/SG8SeBH7xkdK+ItPkLkUfVtCGgqqmhJkfVyamRS0ZqprXL/GMsZw1Ac543/wY9I53 6c/4cpfEH2ahwSPbyfkbcfU+9h/3SpSnqNi4NFD9U5C0agDzPZf8rBOQOQ1qepKxKpZC sp1Z5alaOj82A/Nm1L3jcDtmuiFaFMRqWcXJUMjngHQaDa1JvGPm9iUmV9LfLEqnlI0r Oh63C956+bqmv7fJXMePb1d9yEzxifDVh7s88sb7N0sd/TCDnvuD2XQ1lHq5KCr/M2Ev i3OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RJqMhQChawsyvn1lusI/GblL/4qcbpXoYzXN+67HPwc=; b=OCYLVg4oha3a2koZca57/4pw+3f3JAAFSOl2j6kIVuO1uikgRMicbUA95xJGg3kX5m QmYHtIW/J9y5PEYa0yihROEidmjIUWqdsouWqGfEocLKWFCvpCCm8kBS/2ZAqoqDup4L w9UhMnmXM66qrv2T+corVjG90EL1h0UXiYGkqaCWDu6APCnt1trXSHzbL5T+WI0zocmU ZVNo2pBZ0bA13Ot/Ym27YIMBkFvQEvx6xIIT1VhDBId/UM3Tvk94V2Kxu1/ARz4ebMNH ugw+RVe+YxdpDNb+JURpxHV2lkoe/hrShmnpns4LdXa9n++DWEplMCG9ihQKWvmCeLyg wJew== X-Gm-Message-State: AEkoouu0zv72dqYyK2jjq1c9+aRAHQX9unyJvgBlQBulgSQjO3KjuwMlxAb6QacWvU2nplkDDnrSHs84iHxUYg== X-Received: by 10.176.69.180 with SMTP id u49mr24244973uau.24.1470009491951; Sun, 31 Jul 2016 16:58:11 -0700 (PDT) Original-Received: by 10.103.148.137 with HTTP; Sun, 31 Jul 2016 16:58:11 -0700 (PDT) In-Reply-To: <831t29prpq.fsf@gnu.org> X-Google-Sender-Auth: EFvPWlZMmWXsv42-L9CVsy61-dU X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::242 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206293 Archived-At: --94eb2c11ab089598dd0538f741c4 Content-Type: text/plain; charset=UTF-8 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 wrote: > > From: Rocky Bernstein > > 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 , 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. --94eb2c11ab089598dd0538f741c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for trying out the package and your detailed commen= ts. As you probably know as an emacs maintainer, feedback and bug reporting= is very helpful.

Although I'll make some general co= mments here and some more specific ones below inline, bug reporting for ELP= A packages isn't something that generally goes on in emacs-devel. Issue= tracking for this package is currently done in =C2=A0https://github.com/realg= ud/realgud/issues=C2=A0. If=C2=A0you look there, some of the concerns y= ou raise, have already been reported.

I'm sure= =C2=A0I don't have to tell you as an emacs maintainer the value of sep= arating out bugs into individual reports so that they can be tracked separa= tely. So I invite you to look at the list of issues and report those that h= aven't been mentioned raised or add comments to the ones that have wher= e 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 replace= ment for "gud.el" called "realgud.el" is
> now in elpa.
>
> I make lots of mistakes (which is why I work on debuggers), so no doub= t there will need to be some
> adjustment. Feel free to dig in or let me know.

Thanks.=C2=A0 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.=C2=A0


It must have been from the git r= epo, since last I tried installing via ELPA, as I reported, subdirectories = were missing.=C2=A0

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.=C2=A0 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 discourag= ement. But please use the issue tracker for reasons mentioned above.
<= div>

Here are the comments:

1. The package needs additional dependencies to start working:

=C2=A0 =C2=A0load-relative
=C2=A0 =C2=A0loc-changes
=C2=A0 =C2=A0list-utils

The dependency = on list-utils has been dropped. You probably need to update your elpa git r= epo if you are still seeing this. As for load-relative and loc-changes, the= y 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 preci= se and add it as an issue in the github tracker.

<= br>

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

<= /div>
It is possible that on Microsoft Windows environments it will fai= l 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.=C2=A0

after a longish delay
=C2=A0 =C2=A0(probably used for looking up files in the current directory).=
=C2=A0 =C2=A0When I type "./emacs.exe RET", it says:

=C2=A0 =C2=A0 =C2=A0emacs.exe is large (66.6M), really open? (y or n)

=C2=A0 =C2=A0This prompt was unexpected, since Emacs doesn't need to vi= sit the
=C2=A0 =C2=A0executable.

File an issue = on this.=C2=A0

=C2=A0 =C2=A0Answering "y" causes another unexpected message in t= he echo area:

=C2=A0 =C2=A0 Debugger track mode is already enabled.

=C2=A0 =C2=A0Why "already"?=C2=A0 And why is it important for me = to know that mode is
=C2=A0 =C2=A0already active?=C2=A0 (The message sounds as if I made some mi= stake.)

Probably one of the many bugs t= hat needs to be track down.=C2=A0
=C2=A0

3. The UI is the old GUD style, without the additional windows
=C2=A0 =C2=A0available with gdb-mi.el, and features available in those wind= ows.

=C2=A0 =C2=A0I think a modern debugger UI should be similar to what other I= DEs
=C2=A0 =C2=A0offer, and gdb-mi is much closer to that ideal than either GUD= or
=C2=A0 =C2=A0realgud.

=C2=A0
= I've looked at gdb-mi and how it handles windows and it feels to me a b= it 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.
=C2=A0

4. The GDB interface used is annotations, which is deprecated by the
=C2=A0 =C2=A0GDB developers, not the more modern MI.=C2=A0 Moreover, the an= notations
=C2=A0 =C2=A0emitted by GDB are actually shown in the command buffer.=C2=A0= Example:

=C2=A0 =C2=A0Temporary breakpoint 3, main (argc=3D2, argv=3D0xa412f8) at em= acs.c:674
=C2=A0 =C2=A0^Z^Zd:\foo\bar\src\emacs.c:674:19557:beg:0x11517b0
=C2=A0 =C2=A0(gdb) n
=C2=A0 =C2=A0^Z^Zd:\foo\bar\src\emacs.c:675:19578:beg:0x11517b7
=C2=A0 =C2=A0(gdb)

=C2=A0 =C2=A0I don't think seeing these annotations is useful; gud.el d= oesn't
=C2=A0 =C2=A0show them.

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

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 g= db-mi.=C2=A0

And/or dig in and help improve gdb su= pport.


5. Completion seems to always complete on file names, even when typing
=C2=A0 =C2=A0parts of GDB commands that have nothing to do with file names.=
=C2=A0 =C2=A0E.g., typing TAB at (gdb) prompt mostly says "No match&qu= ot;, but if you
=C2=A0 =C2=A0type "sea TAB", it will complete to search.c (when t= he default
=C2=A0 =C2=A0directory is the Emacs src directory).=C2=A0 My guess is that = the
=C2=A0 =C2=A0completion is either not delegated to GDB, but instead attempt= ed by
=C2=A0 =C2=A0the package itself, or the completion provided by GDB is used<= br> =C2=A0 =C2=A0incorrectly.=C2=A0 Because GDB has no problems with completing= each
=C2=A0 =C2=A0command correctly.

Probably a = bug. Submit an issue.
=C2=A0

6. The support for displaying values of variables in tooltips requires
=C2=A0 =C2=A0a click; the original GUD didn't, which IMO was more conve= nient.

=C2=A0
For gdb this ma= kes sense. However in most cases it was disabled for a reason. In other lan= guages you are running eval and that can be state changing,
So fo= r 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 wit= h the way other things work. I'm kind of ambivalent. If someone propose= s 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
=C2=A0 =C2=A0the fringe; a second click deletes the breakpoint, but the fri= nge
=C2=A0 =C2=A0marker is not removed.=C2=A0 Additional clicks on that marker = cause a
=C2=A0 =C2=A0"delete N" command to be again sent to GDB, which re= sponds with an
=C2=A0 =C2=A0error message.

I think thi= s bug has been reported,.=C2=A0
=C2=A0

8. Clicking the "Next" button on the tool bar leaves a fading tra= ce of
=C2=A0 =C2=A0the previous stop points (arrow1, arrow2, etc.), which is nice= .
=C2=A0 =C2=A0However, the same trace is displayed in the command buffer, wh= ere I
=C2=A0 =C2=A0think it's unnecessary and confusing.=C2=A0 In fact, for t= he arrow to be
=C2=A0 =C2=A0shown in the command buffer is something I don't expect.= =C2=A0 On a TTY
=C2=A0 =C2=A0frame, showing these arrows in the command buffer overwrites t= he
=C2=A0 =C2=A0GDB prompts and other information in the 1st 2 columns of each= line
=C2=A0 =C2=A0where 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,<= br> =C2=A0 =C2=A0which I think is unfortunate.=C2=A0 One other omission I spott= ed is the
=C2=A0 =C2=A0GNU Awk's built-in debugger.

Ah - this is a common comment.=C2=A0

When r= ms wrote emacs he designed it with it being "extensible" and &quo= t;modular". In the description of realgud I in fact use the term "= ;modular" too and was very much thinking of rms's description of e= macs. I'll also probably add the word "extensible".=C2=A0

"Extensible" here I think meant not that rm= s 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.=C2=A0
Although I was aware that there is a debugger for GNU Make, I was not previously a= ware that there was one for GNU awk. But that's okay, I just learned th= is and this is good to know.
I took a look at it and it seems ver= y straightforward to add. It probably could be added in a couple of hours o= r so.

However, I'm not a big user of GNU awk a= nd it is not something I will probably be able to =C2=A0undertake or suppor= t.=C2=A0

But as I said, this question though comes= up a lot. And so I have written instructions for how to add a new debug= ger. These instructions are a little github centric, but I'm sure y= ou 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
=C2=A0 =C2=A0hang, but doesn't display anything.

<= /div>
Another bug I think already reported for other debuggers, but not= on gdb, Is probably related to MS Windows interaction.=C2=A0

Thanks again for working on this.

Thank= s for your feedback.=C2=A0

--94eb2c11ab089598dd0538f741c4--