From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Window/buffer management in gdb-ui Date: Thu, 25 Nov 2004 23:21:18 -0500 Message-ID: <87d5y1gsmk.fsf-monnier+emacs@gnu.org> References: <16805.16406.567084.398496@farnswood.snap.net.nz> <87hdndapae.fsf-monnier+emacs@gnu.org> <16806.29150.178158.7827@farnswood.snap.net.nz> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1101442933 32084 80.91.229.6 (26 Nov 2004 04:22:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 26 Nov 2004 04:22:13 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 26 05:22:08 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CXXcU-00019R-00 for ; Fri, 26 Nov 2004 05:22:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CXXli-0003PC-FT for ged-emacs-devel@m.gmane.org; Thu, 25 Nov 2004 23:31:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CXXlN-0003Oz-BX for emacs-devel@gnu.org; Thu, 25 Nov 2004 23:31:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CXXlM-0003OP-7P for emacs-devel@gnu.org; Thu, 25 Nov 2004 23:31:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CXXlM-0003OM-4G for emacs-devel@gnu.org; Thu, 25 Nov 2004 23:31:16 -0500 Original-Received: from [209.226.175.93] (helo=tomts36-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CXXbj-0004aZ-Jt for emacs-devel@gnu.org; Thu, 25 Nov 2004 23:21:20 -0500 Original-Received: from alfajor ([65.92.240.13]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041126042119.OPWW1613.tomts36-srv.bellnexxia.net@alfajor>; Thu, 25 Nov 2004 23:21:19 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id C1926D73CB; Thu, 25 Nov 2004 23:21:18 -0500 (EST) Original-To: Nick Roberts In-Reply-To: <16806.29150.178158.7827@farnswood.snap.net.nz> (Nick Roberts's message of "Fri, 26 Nov 2004 12:59:26 +1300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) 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: main.gmane.org gmane.emacs.devel:30375 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30375 >> > gdb-display-buffer was part of gdba.el. It did extra things like not >> > replace the window with the GUD buffer with new content. Perhaps >> > display-buffer could be used but now I make new gdb-related windows >> > dedicated here >> >> Why do you make the window dedicated. I think a window should only be made >> dedicated when it's created. If you take a preexisting window that >> potentially shows any buffer (even unrelated to GDB-UI) and make it >> dedicated it'll screw things up sooner or later. > Its the only way, that I know of, to protect the contents of a window. Well, I know what it does. My question had to do with the end goal: "protect the contents of a window" is not very clear. Which scenario are you trying to avoid? > I think I only make the windows dedicated *after* I put the gdb-related > stuff in them. I take your point that dedicated windows can be > a nuisance. Thats why I try to undedicate any source buffers left after > a debug session. The special-frames-regexp seems to make the window > dedicated indirectly and so, to be honest, I can't see how this differs, > in practice, from what I had before. The special-buffer-regexp thingy is used at a place where the window has just been created. The problem is in gdb-display-buffer where you reuse a preexisting window (the one returned by get-lru-window) which might display any random buffer. Dedicated windows are not a problem in and of themselves (most of my windows are dedicated). The problems come when you take a non-dedicated window which the user used for some purpose and "you" suddenly hijack it by making it dedicated. So I suggest to change gdb-display-buffer further and only call set-window-dedicated-p in the `must-split' branch (i.e. only call it on the window you've just created): -- gdb-ui.el 25 nov 2004 10:24:41 -0500 1.34 ++ gdb-ui.el 25 nov 2004 23:16:19 -0500 @@ -1608,8 +1608,8 @@ (cur-size (window-height largest)) (new-size (and size (< size cur-size) (- cur-size size)))) (setq answer (split-window largest new-size)) - (set-window-buffer answer buf))) - (set-window-dedicated-p answer t) + (gdb-set-window-buffer answer buf)) + (set-window-dedicated-p answer t)) answer))) (defun gdb-display-source-buffer (buffer) You could almost reuse gdb-set-window-buffer on those two new lines, BTW. >> > It doesn't seem to interfere with the setups that I'm thinking of, so I've >> > installed these changes. I don't really know what the change below does >> > but gdb-frame-breakpoints-buffer is one of a family of commands accessible >> > from the menubar (GUD->GDB Frames->...) so should these be changed also? >> >> I think so, yes. >> What it does is that it allows users to specify the behavior they want in >> special-display-regexp or special-display-buffer-names. > I've changed these (apart from gdb-frame-gdb-buffer because the gud buffer > is covered by same-window-regexps). I've removed the menubar and minibuffer > from the resulting frames using special-display-frame-alist (maybe this > make no difference with your setup). Indeed ;-) > I tried not to select the buffer by using display-buffer instead of > pop-to-buffer but it still seems to select it anyway (Is this a bug in > Emacs?). I'm not sure whether it's a bug or not, but I've seen this behavior. Maybe you should report it for others to judge whether it's a bug or not. You can of course wrap the whole thing inside `with-current-buffer' if that's a problem (I seem to remember doing exactly that in some code, maybe for PCL-CVS?). Stefan