From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Re: Starting multiple GUD session; doc problem Date: Sun, 26 Nov 2006 17:53:08 +1300 Message-ID: <17769.7604.137412.491382@kahikatea.snap.net.nz> References: <17767.37609.24236.660750@kahikatea.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1164522743 4856 80.91.229.2 (26 Nov 2006 06:32:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 26 Nov 2006 06:32:23 +0000 (UTC) Cc: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 26 07:32:17 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GoDYm-0007HX-Hi for ged-emacs-devel@m.gmane.org; Sun, 26 Nov 2006 07:32:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GoDYm-0001Tu-27 for ged-emacs-devel@m.gmane.org; Sun, 26 Nov 2006 01:32:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GoDYZ-0001Tl-GK for emacs-devel@gnu.org; Sun, 26 Nov 2006 01:32:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GoDYY-0001TT-1S for emacs-devel@gnu.org; Sun, 26 Nov 2006 01:32:02 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GoDYX-0001TQ-Ud for emacs-devel@gnu.org; Sun, 26 Nov 2006 01:32:01 -0500 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GoDYX-0006gR-Bv for emacs-devel@gnu.org; Sun, 26 Nov 2006 01:32:02 -0500 Original-Received: from kahikatea.snap.net.nz (p202-124-120-99.snap.net.nz [202.124.120.99]) by viper.snap.net.nz (Postfix) with ESMTP id 75B7030CC7A; Sun, 26 Nov 2006 17:58:03 +1300 (NZDT) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id EE248BE440; Sun, 26 Nov 2006 17:53:09 +1300 (NZDT) Original-To: Stephen Leake In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.91.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:62806 Archived-At: > > > I just tried to start two gdb sessions in one CVS Emacs session for > > > the first time (I've done this many times in Emacs 21). I got the > > > error message: > > > > > > "gdb: Multiple debugging is only supported with "gdb --fullname" > > > > > > So I dutifully added "--fullname" to the gdb command line: > > > > > > gdb --annotate=3 --fullname gds-main_models_test.exe > > > > Well, I'm not sure that's dutiful, it means start with "gdb --fullname" > > _instead of_ "gdb --annotate=3" but if other's find it ambiguous too > > I'll change it. > > Since the info manual never mentions "--annotate=3", I thought it was > always necessary. So yes, I found it ambiguous. I guess it presupposes a knowledge of "--fullname" and "--annotate=3". Ideally it would mention neither but give the user the option of switching between the two in terms of their functionality. > But I run "gdb" without "--fullname" all the time in Emacs 21. I > thought that meant gud was searching the directory path in > compilation-search-path. It gets added by Emacs, it's just not displayed in the minibuffer. See gud-gdb-massage-args. > However, testing on Emacs 22, I see the --fullname is required now. > > > The current doc string goes on to explain what how this function > > lays out the buffers. To the first time user what would GUI mode > > mean? > > Good point. On the other hand, the first sentence in 32.6.5 mentions a > "graphical interface"; so that would be a good place to define "GUI > mode". > > > The other changes are wrong because "--fullname" is needed. Perhaps > > some confusion arises over the term "text command mode". It refers > > to the way that it works in Emacs 21: GUD buffer + source buffer. > > Right, I did understand that. "gdb --fullname" works the same in Emacs > 22 as "gdb" in Emacs 21, They work the same because they _are_ the same i.e. both use --fullname. > and that is the behavior I was expecting. In > particular, I don't have to do anything special to get two debugging > sessions. > > At the same time, if you don't customize 'gdb-many-windows', "gdb > --annotate=3" in Emacs 22 also works the same as "gdb" in Emacs 21, > except that it doesn't allow multiple debugging sessions. So that's > why I was surprised by this. I've arranged so that it starts up the same way. However it has much more functionality. If you create a breakpoint a red bullet is placed in the fringe/margin so you don't have to remember where your breakpoints are. You can view the stack, examine watch expressions, manipulate breakpoints... > GUI mode (with 'gdb-many-windows' t) adds a fancy display (which I > find annoying; I prefer my screen real estate to show actual code :). Many people like to set gdb-many-windows to t but the default value is nil If you don't want to use it, don't change it's value. > It also adds tooltips for viewing variables, which is very nice. GUD Tooltips are available for Emacs 21 but they are rather awkwad to turn on and off. > (aside; I don't understand why the tooltips are not available in "text > command mode". Is "--annotate" required to get tooltip variable values?) The section Debugger Operation says GUD tooltips are disabled when you use GDB in text command mode (*note GDB Graphical Interface::), because displaying an expression's value in GDB can sometimes expand a macro and result in a side effect that interferes with the program's operation. The GDB graphical interface supports GUD tooltips and assures they will not cause side effects. > > Perhaps it would help to refer to "text command mode" in the section > > "Debugger Operation" (it currently says "using the textual > > interface"). > > Yes, that would help. I think "text command mode" and textual interface (and graphical interface) are RMS' terms. Let's see what he thinks. > Hmm. The first paragraph there says the program input and output is > via the GUD buffer, in text command mode. However, it doesn't say > where they are in GUI mode; That's because the graphical interface is described in a later section > are there separate buffers for that? Hmm. > I just tried it, and the answer seems to be "no"; The answer is yes. See GDB User Interface Layout > stdin and stdout are > still mixed in the GUD buffer in GUI mode. Perhaps there is another > variable to customize? gdb-use-separate-io-buffer. See Other GDB-UI Buffers. I think it's only fair that you read what is in the manual first. > I'm running GNU gdb 5.3 for GNAT Pro 5.04a > (20060125), compiling Ada code. 5.3 sounds old to me. Even if you use FSF GDB (6.6 shortly) you should be able to debug Ada code. I've even tested expanding/contracting arrays as watch expressions in the speedbar. >... > If it was totally up to me, I'd make "M-x gdb" in Emacs 22 do "gdb > --fullname" by default, since that is closest to the Emacs 21 behavior > (it allows multiple debugging sessions). Fortunately it's not up to you. The aim of Emacs 22 is to improve upon Emacs 21 not emulate it. Could you please experiment with the new features and report your findings so that we can improve it further. > To get the GUI mode, you > would do "M-x gdba". (And that's how I've customized things in my > .emacs). > > That means people would have to read the manual to know about the GUI > mode. The default behaviour is generally the one which is most useful. > But that is the case now anyway; you have to set > 'gdb-many-windows' to get the GUI mode multiple windows display when > starting with "M-x gdb", Other buffers can be displayed manually from the menu bar without setting it. > and you have to read the manual to know that. > You also have to read the manual to know about the additional mouse > bindings. It is true that you need to read the manual to understand the new features, and that's not a bad thing, but I think many are fairly intuitive if you have experience of graphical debuggers. > I've attached an updated patch. Please don't. There's currently no consensus that your changes are the right ones. -- Nick http://www.inet.net.nz/~nickrob