From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: display-buffer cleverness - how to tame? Date: Tue, 5 May 2009 07:18:02 -0700 Message-ID: <004901c9cd8c$4d902e60$0200a8c0@us.oracle.com> References: <000c01c9cc8b$ba796c50$0200a8c0@us.oracle.com> <49FEA973.70705@gmx.at> <002a01c9ccc6$2221c840$0200a8c0@us.oracle.com> <49FF1AA0.9080601@gmx.at> <000e01c9ccdb$b0997180$c2b22382@us.oracle.com> <49FFE481.1070102@gmx.at> 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 1241533244 5933 80.91.229.12 (5 May 2009 14:20:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 May 2009 14:20:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'martin rudalics'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 05 16:20:34 2009 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 1M1LVZ-0003Gw-AP for ged-emacs-devel@m.gmane.org; Tue, 05 May 2009 16:20:33 +0200 Original-Received: from localhost ([127.0.0.1]:47104 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1LVY-0008DV-NB for ged-emacs-devel@m.gmane.org; Tue, 05 May 2009 10:20:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1LTS-0006ir-Fa for emacs-devel@gnu.org; Tue, 05 May 2009 10:18:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1LTN-0006dw-Qz for emacs-devel@gnu.org; Tue, 05 May 2009 10:18:21 -0400 Original-Received: from [199.232.76.173] (port=40173 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1LTN-0006dr-EV for emacs-devel@gnu.org; Tue, 05 May 2009 10:18:17 -0400 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:49422 helo=rgminet11.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M1LTM-0006QB-Ix for emacs-devel@gnu.org; Tue, 05 May 2009 10:18:17 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n45EIK0r022426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 May 2009 14:18:22 GMT Original-Received: from abhmt005.oracle.com (abhmt005.oracle.com [141.146.116.14]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n45EI5oN004914; Tue, 5 May 2009 14:18:06 GMT Original-Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 May 2009 07:18:03 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49FFE481.1070102@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnNUCR8u5SBEzxLSwWsw6/Hcs0HSQAOb1bg X-Source-IP: abhmt005.oracle.com [141.146.116.14] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4A004A9C.022E:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 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:110679 Archived-At: > > The question I have now is how to impose, in a particular call to > > `display-buffer', *not* splitting a window if it is not > > full-width? That is, how > > to reinstate that pre-Emacs 23 splitting criterion (temporarily)? > > Emacs 22 did split a non-full-width window vertically and from your > previous posts you even relied on and wanted that behavior. The only > new twist is that Emacs 23 may split the non-full-width largest window > even when it's not the least recently used one. So the question is, then, how to get Emacs 23 to not split that (non-full-width largest) window if it is not the lru window? > > I'd also like to know how to tell `display-buffer' not to > > split the selected window, and how to tell it specifically > > which window to split. Those approaches would also solve the > > problem I see here (in alternative ways), and that > > knowledge would be generally helpful (to me, at least). > > That's what `split-window-preferred-function' is all about. It gets > called with the window to split and you can temporarily bind your own > function to that. That function would check if the window to split is > the selected one and, if that is the case, split another one instead > provided such a window exists. BTW, your example is a second > reason why `split-window-preferred-function' should be called with an > argument, so I plan to leave the current calling convention alone. OK, thanks. However, the doc string for `split-window-preferred-function' is not clear (to me). First, this sentence is not grammatically correct; I can't understand it: "If non-nil, a function called with a window as single argument supposed to split that window and return the new window." That seems to say that the window argument is supposed to split itself, or something like that. >From your description above, the function decides, based on a window passed as arg, which window to split, and then splits the window it chooses. Is that correct? Why is a particular window passed as arg, if the choice of which window to split is up to the function? Is there some usual interpretation/use of that window arg? When `display-buffer' calls `split-window-preferred-function', which window does it pass as arg? What is the role/meaning of that window; how does `display-buffer' pick it? You say the function is called "with the window to split", but what does that mean, if it is the function itself that decides which window to split (and splits it)? This info seems to be missing. At least it's not clear to me. > >> and (2) would have failed to DTRT with > >> more than two windows on your frame or the window on the > >> right not being the least recently used one. > > > > Which is not a problem here - that cannot be the case in > > my context. But it is good to know. > > If you as designer are in full control of the context then why do you > rely on `display-buffer' in the first place? The whole idea of > `display-buffer' is to shift control to the users' customizations ... I'm sure you don't want the details of the code. If you do, we can take it off the list. And yes, there are no doubt alternative ways to code what I need.