From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.help Subject: Re: GUD/GDB in emacs Date: Sat, 19 Jul 2008 14:03:36 +1200 Message-ID: <18561.19320.854676.502740@kahikatea.snap.net.nz> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1216434328 413 80.91.229.12 (19 Jul 2008 02:25:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Jul 2008 02:25:28 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Richard G Riley Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jul 19 04:26:15 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KK29H-0000Hm-BM for geh-help-gnu-emacs@m.gmane.org; Sat, 19 Jul 2008 04:26:15 +0200 Original-Received: from localhost ([127.0.0.1]:60365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KK28O-0003Ap-FK for geh-help-gnu-emacs@m.gmane.org; Fri, 18 Jul 2008 22:25:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KK285-0003Aa-FG for help-gnu-emacs@gnu.org; Fri, 18 Jul 2008 22:25:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KK283-0003AH-0z for help-gnu-emacs@gnu.org; Fri, 18 Jul 2008 22:25:00 -0400 Original-Received: from [199.232.76.173] (port=50007 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KK282-0003AE-Ss for help-gnu-emacs@gnu.org; Fri, 18 Jul 2008 22:24:58 -0400 Original-Received: from viper.snap.net.nz ([202.37.101.25]:44746) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KK282-0001i1-5Z for help-gnu-emacs@gnu.org; Fri, 18 Jul 2008 22:24:58 -0400 Original-Received: from kahikatea.snap.net.nz (229.63.255.123.dynamic.snap.net.nz [123.255.63.229]) by viper.snap.net.nz (Postfix) with ESMTP id E73F82F540C; Sat, 19 Jul 2008 14:03:45 +1200 (NZST) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id C97A18FC6D; Sat, 19 Jul 2008 14:03:37 +1200 (NZST) Original-Newsgroups: gnu.emacs.help In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.2.50.3 X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:55723 Archived-At: Richard G Riley writes: > Nick Roberts writes: > > > > > I'm not sure what you mean exactly. Maybe expand a node in situ in the > > > > locals buffer, for example. > > > > > > That would seem the obvious solution and is the case in other IDEs. e.g > > > you see "p" in the locals (where p is a pointer to a struct for example) > > > and then can see the struct by double clicking it for example. Pretty > > > much what the speedbar does but without the speed bar. > > > > > > I think Insight does this but ISTR Totalview uses a separate frame. > > Expanding > > I'm not familiar with these things. They are Emacs packages? No, they're debuggers. > > in situ makes it harder to find the other locals. In fact I'm > > thinking of > > Expand, shrink. They only impede if you expand them. If you expand them > they are expanded for a reason generally. But as you point out below the > vocab we are using (because of what is there) can confuse us. "Watch" in > this case is the only apparent way to expand a pointer to a struct. We > should really just be discussing how to view a dereferenced pointer - > DDD does this quite nicely. But being an Emacs convert it would be nice > to have the same, or similar, in the GUD interface. I've not used DDD much but I found the data window (= watch expressions?) awkward. You can view structures in the GUD buffer with "set print pretty" and the "print" command (also on the tool bar and C-x C-a C-p). > > using a separate frame for each watch expression, something which isn't > > really possible with the speedbar. This would be helpful for arrays and > > large structures. > > A separate frame for each expression would be a collossal waste of > screen real estate and possibly worse than the current speed bar > implementation IMO. As you say, they only impede if you expand them. Data structures can be large and need their own frame/window. It would also be a way to limit the number of children that need to be created. -- Nick http://www.inet.net.nz/~nickrob