From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: realgud now in elpa Date: Sun, 31 Jul 2016 21:50:25 +0300 Message-ID: <831t29prpq.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1469991116 19009 80.91.229.8 (31 Jul 2016 18:51:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2016 18:51:56 +0000 (UTC) Cc: clement.pitclaudel@live.com, emacs-devel@gnu.org To: Rocky Bernstein Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 20:51:36 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 1bTvpo-0004tO-Dp for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2016 20:51:36 +0200 Original-Received: from localhost ([::1]:40496 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTvpk-0001aN-IG for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2016 14:51:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTvpB-0001a5-Nu for emacs-devel@gnu.org; Sun, 31 Jul 2016 14:51:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTvp9-0002fW-Gh for emacs-devel@gnu.org; Sun, 31 Jul 2016 14:50:56 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60483) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTvp3-0002es-Gn; Sun, 31 Jul 2016 14:50:49 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3882 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bTvoz-0005MN-Hk; Sun, 31 Jul 2016 14:50:48 -0400 In-reply-to: (message from Rocky Bernstein on Sat, 30 Jul 2016 10:56:33 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:206278 Archived-At: > 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. 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.