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: gdb-ui, dedicated windows Date: Sat, 5 Jul 2008 22:02:29 +1200 Message-ID: <18543.18102.11098.763936@kahikatea.snap.net.nz> References: <87zlowwyn1.fsf@localhorst.mine.nu> 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 1215252189 27143 80.91.229.12 (5 Jul 2008 10:03:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jul 2008 10:03:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Hansen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 05 12:03:53 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 1KF4cS-00085T-G1 for ged-emacs-devel@m.gmane.org; Sat, 05 Jul 2008 12:03:52 +0200 Original-Received: from localhost ([127.0.0.1]:33577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KF4bb-0004jE-Er for ged-emacs-devel@m.gmane.org; Sat, 05 Jul 2008 06:02:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KF4bU-0004i3-N2 for emacs-devel@gnu.org; Sat, 05 Jul 2008 06:02:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KF4bQ-0004fJ-QT for emacs-devel@gnu.org; Sat, 05 Jul 2008 06:02:50 -0400 Original-Received: from [199.232.76.173] (port=40647 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KF4bQ-0004fF-LK for emacs-devel@gnu.org; Sat, 05 Jul 2008 06:02:48 -0400 Original-Received: from viper.snap.net.nz ([202.37.101.25]:38507) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KF4bP-00065N-Kn for emacs-devel@gnu.org; Sat, 05 Jul 2008 06:02:48 -0400 Original-Received: from kahikatea.snap.net.nz (233.30.255.123.static.snap.net.nz [123.255.30.233]) by viper.snap.net.nz (Postfix) with ESMTP id 5C82F3DA3B1; Sat, 5 Jul 2008 22:02:37 +1200 (NZST) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id D49478FC6D; Sat, 5 Jul 2008 22:02:31 +1200 (NZST) In-Reply-To: <87zlowwyn1.fsf@localhorst.mine.nu> 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: 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:100364 Archived-At: > when `gdb-many-windows' is nil some windows (e.g. the window displaying > the stack buffer) are dedicated. > > This may make sense with `gdb-many-windows' set to t but I find it > pretty annoying with a nil value. I just looked at a long stack trace > displayed in the only window of the frame. Dedicating windows gives some control over window configuration. Even if gdb-many-windows is nil the user might choose to display buffers manually that give a similar configuration to when it is t. > When I hit RET to jump to the interesting source Emacs popped up a new > frame. IMHO it's very bad behavior to pop up a frame unless explicitly > asked to do so. I use gdb-many-windows with a nil value and often just display the stack trace in a separate frame (via the menubar) and I don't see this. There must be other factors like pop-up-frames being t, or the GUD and/or source buffer killed or not being visible etc. In order for me to accommodate your pattern of use, you need to provide a recipe that illustrates the problem. > Do these windows have to be dedicated? Not making them dedicated might fix your specific problem but would surely cause others. Currently window placement relies on heuristics and it will probably always be possible to find a usage pattern where gdb-ui has annoying behaviour. It is this kind of problem, inspired by examining ECB, that has led to some people to look at the concept of window groups, as discussed earlier this year on the mailing list. > Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a > dedicated window even if `gdb-many-windows' is t. It just takes to much > space and makes it hard to look at two source files at the same time. If it takes up too much room why use a separate buffer? If you need a separate buffer, why not put it in another frame? > BTW, how about some key bindings to move around / display the gdb-ui > windows? It would be nice to be able to move the buffers around like views in Eclipse but that would be a substantial task. Emacs 23 has tabs in the header line of some buffers. Do you have any concrete ideas? -- Nick http://www.inet.net.nz/~nickrob