From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: gdb-ui, dedicated windows Date: Tue, 15 Jul 2008 22:37:02 +0900 Message-ID: References: <87zlowwyn1.fsf@localhorst.mine.nu> <18543.18102.11098.763936@kahikatea.snap.net.nz> <87vdzkwqlr.fsf@localhorst.mine.nu> <18545.40372.978280.247737@kahikatea.snap.net.nz> <18547.64152.956371.924404@kahikatea.snap.net.nz> <871w24ndmd.fsf@catnip.gol.com> <18548.38718.630083.307385@kahikatea.snap.net.nz> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216129056 27847 80.91.229.12 (15 Jul 2008 13:37:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jul 2008 13:37:36 +0000 (UTC) Cc: David Hansen , emacs-devel@gnu.org To: Nick Roberts Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 15 15:38:24 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KIkjN-0001Yd-Bz for ged-emacs-devel@m.gmane.org; Tue, 15 Jul 2008 15:38:13 +0200 Original-Received: from localhost ([127.0.0.1]:35834 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIkiV-0007lc-3P for ged-emacs-devel@m.gmane.org; Tue, 15 Jul 2008 09:37:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KIkiR-0007lC-Fa for emacs-devel@gnu.org; Tue, 15 Jul 2008 09:37:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KIkiQ-0007l0-0X for emacs-devel@gnu.org; Tue, 15 Jul 2008 09:37:15 -0400 Original-Received: from [199.232.76.173] (port=46960 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIkiP-0007kx-Rz for emacs-devel@gnu.org; Tue, 15 Jul 2008 09:37:13 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.193]:50952) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KIkiL-000101-OG; Tue, 15 Jul 2008 09:37:10 -0400 Original-Received: from relay31.aps.necel.com ([10.29.19.54]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m6FDaYb3010409; Tue, 15 Jul 2008 22:37:04 +0900 (JST) Original-Received: from relay21.aps.necel.com ([10.29.19.20] [10.29.19.20]) by relay31.aps.necel.com with ESMTP; Tue, 15 Jul 2008 22:37:04 +0900 Original-Received: from dhapc248.dev.necel.com ([10.114.112.215] [10.114.112.215]) by relay21.aps.necel.com with ESMTP; Tue, 15 Jul 2008 22:37:04 +0900 Original-Received: by dhapc248.dev.necel.com (Postfix, from userid 31295) id 93F0C5A7; Tue, 15 Jul 2008 22:37:03 +0900 (JST) System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <18548.38718.630083.307385@kahikatea.snap.net.nz> (Nick Roberts's message of "Wed, 9 Jul 2008 22:47:26 +1200") Original-Lines: 30 X-detected-kernel: by monty-python.gnu.org: Solaris 8 (1) 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:100735 Archived-At: Nick Roberts writes: > > A possible fix would be to store the buffer gdb puts in that window, > > and when deciding whether to re-use that window or, also verify that the > > same buffer is there (and don't re-use the window if not). > > gdb-ui _does_ store the (source) buffer it puts in the window. That's why when > you replace it with the GUD buffer using switch-to-buffer (not part of gdb-ui) > it gets confused. > > It could verify that the same buffer is there but the contents of the source > window change every time the program being debugged stops in a frame that is in > a different file and gdb-ui must allow for this. Why is this a problem? In such cases, the source buffer should get changed via gdb-display-source-buffer, which will update the associated source-file, right? In other words, it seems that as long as gud is the one doing the updating of the source window, everything will remain consistent, and it will keep using that window. It would only be if some external agent changes what's displayed in that window that the state would become inconsistent -- and in that case, it's probably the right thing to do to pop up a new window (which will become the new source window). Anyway, I can make the obvious change and see if it feels funny. -Miles -- Optimist, n. A proponent of the doctrine that black is white.