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: {Spam?} Window/buffer management in gdb-ui Date: Wed, 24 Nov 2004 15:42:54 -0500 Message-ID: References: <16804.60027.817610.776972@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 1101329070 1136 80.91.229.6 (24 Nov 2004 20:44:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 24 Nov 2004 20:44:30 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 24 21:44:18 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 1CX3zt-0008DR-00 for ; Wed, 24 Nov 2004 21:44:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CX493-0002yd-Ce for ged-emacs-devel@m.gmane.org; Wed, 24 Nov 2004 15:53:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CX48U-0002rT-4h for emacs-devel@gnu.org; Wed, 24 Nov 2004 15:53:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CX48S-0002qq-Sp for emacs-devel@gnu.org; Wed, 24 Nov 2004 15:53:09 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CX48S-0002qM-Nr for emacs-devel@gnu.org; Wed, 24 Nov 2004 15:53:08 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CX3yd-0007fe-RD for emacs-devel@gnu.org; Wed, 24 Nov 2004 15:43:00 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 99E788282AD; Wed, 24 Nov 2004 15:42:59 -0500 (EST) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id A22854AC518; Wed, 24 Nov 2004 15:42:55 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 76FF78CA69; Wed, 24 Nov 2004 15:42:55 -0500 (EST) Original-To: Nick Roberts In-Reply-To: <16804.60027.817610.776972@farnswood.snap.net.nz> (Nick Roberts's message of "Thu, 25 Nov 2004 09:09:31 +1300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) X-MailScanner-From: monnier@iro.umontreal.ca 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:30325 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30325 >> - messes up the namespace > I know that standard practice is to prefix such functions, in general, with > gdb but this isn't really a gdb-related function. I felt that the occasional > violation i.e one for the whole of gdb-ui.el, would not cause a problem, in > practice, and may help prevent duplication with locally defined functions > performing the same task. No, that's not how it works. You should define it as gdb- and/or lobby on emacs-devel to add it to some global file like subr.el. >> - it changes the currently selected window and makes it dedicated >> (because we know that (get-buffer-window (switch-to-buffer name)) >> is always equal to (selected-window)) > Its only used when gdb-ui sets up/restores the windows. Hmm... I don't understand. First, there's the problem of using get-buffer-window instead of selected-window (maybe it's not a problem, but I find to be confusing). Then there's the problem of using switch-to-buffer which forcefully hides the previously displayed buffer. And finally there's the problem of marking as dedicated a window that already existed as non-dedicated (and had thus a different purpose). Are you telling me that you always know for sure that the buffer previously displayed is of no interest to the user and can safely be hidden and the window can of course be reused? Is it because the window was just created (and thus displays a random buffer)? >> I understand that maybe my setup is not representative, but maybe if you >> could describe what behavior you're trying to get, I can help you come up >> with a way to code it that doesn't plays nicely in my situation. >> >> I.e. what is the behavior you're trying to get. You can describe it with >> a mix of description of how *you* want it plus some examples of problematic >> behaviors you'd like to avoid (i.e. bug-reports). > I noticed two things. Firstly, when the user displays a gdb-related buffer in > another window (M-x gdb-display-BUFFERTYPE-buffer or from the menubar, GUD-> GDB-Windows->...) it can replace an existing buffer that the user wants > to remain visible. These changes ensure that, in this case, a gdb-related > buffer is split to provide space for the new buffer. Secondly, if the user > wants to do something different in between debugging, visit info or list > buffers, for example, it is best for that buffer to appear in a separate > frame. > Its a `work in progress', I haven't thought it through yet. Since the "feature > freeze" could extend to infinity, I figured I'd have enough time to put it > right. Also, as its been quiet recently, I thought maybe everyone was using > "-fullname". I guess this is one way of finding out! This assumes much too much already. Please start from the beginning and describe to me the behavior you (want to) see in general when you use GDB-UI: where is displayed which buffer (both source buffers and GDB-UI's own buffers), when, etc... >> As for my own setup, I use 1 buffer per frame and 1 frame per buffer with >> a separate dedicated minibuffer. In my setup, any code that uses >> `switch-to-buffer' is a pain in the rear. > You never have split windows? Very rarely. > How do you arrange that? (setq pop-up-frames t) > What is a "separate dedicated minibuffer"? A special frame (typically 1-line tall) that has no window other than a mini-window that displays a minibuffer (i.e. the frame-parameter `minibuffer' is set to `only'). The other frames have no mini-window and use that special frame when they need an echo area or a minibuffer (the frame-parameter `minibuffer' is set to nil). Stefan