From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: display-buffer cleverness - how to tame? Date: Tue, 05 May 2009 09:02:25 +0200 Message-ID: <49FFE481.1070102@gmx.at> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1241510860 29388 80.91.229.12 (5 May 2009 08:07:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 May 2009 08:07:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 05 10:07:31 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 1M1FgZ-0003nB-0E for ged-emacs-devel@m.gmane.org; Tue, 05 May 2009 10:07:31 +0200 Original-Received: from localhost ([127.0.0.1]:58092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1FgY-0001BD-AT for ged-emacs-devel@m.gmane.org; Tue, 05 May 2009 04:07:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1FgS-0001Av-2j for emacs-devel@gnu.org; Tue, 05 May 2009 04:07:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1FgN-0001AY-Cp for emacs-devel@gnu.org; Tue, 05 May 2009 04:07:23 -0400 Original-Received: from [199.232.76.173] (port=49776 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1FgN-0001AV-9T for emacs-devel@gnu.org; Tue, 05 May 2009 04:07:19 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:42516) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1M1FgM-0006L5-Rw for emacs-devel@gnu.org; Tue, 05 May 2009 04:07:19 -0400 Original-Received: (qmail invoked by alias); 05 May 2009 07:07:15 -0000 Original-Received: from 62-47-49-59.adsl.highway.telekom.at (EHLO [62.47.49.59]) [62.47.49.59] by mail.gmx.net (mp046) with SMTP; 05 May 2009 09:07:15 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18sbuQPHjgshu8afglVe5504b+O3nBoBPv1E3Vtyf 20mqc3Vq1mqxOe User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <000e01c9ccdb$b0997180$c2b22382@us.oracle.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:110674 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. > 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. >> 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 ... martin