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: Thu, 07 May 2009 11:37:09 +0200 Message-ID: <4A02ABC5.1030806@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> <49FFE481.1070102@gmx.at> <004901c9cd8c$4d902e60$0200a8c0@us.oracle.com> <4A006A59.1000406@gmx.at> <002301c9cda2$b4acf680$0200a8c0@us.oracle.com> <4A008B8C.4090209@gmx.at> <002d01c9cdbe$e51356e0$0200a8c0@us.oracle.com> <4A01B906.1020605@gmx.at> <006501c9ce73$abde6710$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 1241689154 29332 80.91.229.12 (7 May 2009 09:39:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 May 2009 09:39:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 07 11:39:04 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 1M204E-0005IC-V7 for ged-emacs-devel@m.gmane.org; Thu, 07 May 2009 11:39:03 +0200 Original-Received: from localhost ([127.0.0.1]:56747 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M204E-0001g9-4x for ged-emacs-devel@m.gmane.org; Thu, 07 May 2009 05:39:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M2046-0001g0-EB for emacs-devel@gnu.org; Thu, 07 May 2009 05:38:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M2041-0001f1-Bu for emacs-devel@gnu.org; Thu, 07 May 2009 05:38:53 -0400 Original-Received: from [199.232.76.173] (port=52838 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M2041-0001ey-16 for emacs-devel@gnu.org; Thu, 07 May 2009 05:38:49 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:48217) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1M2040-0000yo-1z for emacs-devel@gnu.org; Thu, 07 May 2009 05:38:48 -0400 Original-Received: (qmail invoked by alias); 07 May 2009 09:38:45 -0000 Original-Received: from 62-47-46-195.adsl.highway.telekom.at (EHLO [62.47.46.195]) [62.47.46.195] by mail.gmx.net (mp026) with SMTP; 07 May 2009 11:38:45 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19ks09TCApkf6rfhl+RCd6bMEnbqBnlMKycKXdrCj D9toezumo7m/rD User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <006501c9ce73$abde6710$c2b22382@us.oracle.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:110748 Archived-At: > Yes, I read it. No, I don't see any such "step-by-step operative description". > I'm looking at the latest pretest. If you've updated the manual since then, then > no, I haven't read your update. This part was written by Eli and I think it's a splendid example of how to combine the operational description of the buffer displaying process with the description of the variables that affect this process. If you don't see that, then I assure you that I can hardly do any better. > There is this sentence: "Precisely how `display-buffer' finds or creates a > window depends on the variables described below." And then the variables are > described. At the end of each description Eli explains how the process continues. > IOW, we say that how it does it what it does depends on the variables. But I > don't see that "how" or even that "what" described in any "step-by-step > operative description". > > Sorry; it's not clear to me from reading that doc (or the doc strings). Please give us at least one or two concrete examples. > Yes, it's there. I can dig out that meaning after several readings. But this > description of `split-height-threshold' is hard to follow: > > "If no window is tall enough, or if the value of > this variable is `nil', `display-buffer' tries to split some window > horizontally, subject to restrictions of `split-width-threshold' > (see below). If splitting horizontally is impossible too, > `display-buffer' splits a window vertically only if it's the only > window on its frame and not the minibuffer window, and only if > `pop-up-windows' is non-`nil'." > > If that description is combined with the description of `split-width-threshold', > then yes, it follows that when both are nil then in most cases no window is > split. But it takes some digging to get that. As a matter of fact that happened because I tried to be more concrete. If I omit such details you'll tell me that you miss them :-( > So `split-window-preferred-function' is now always a function? That would seem > to change quite a lot. Hardly anything. > Looking at the `window.el' code in the pretest, I cannot imagine what the > resulting behavior change will be. Will `window--try-to-split-window' always use > `split-window-preferred-function'? Yes, provided the frame is splittable. > Will the default value of that option then be > some function that calls `window--splittable-p' and takes into account the two > thresholds somehow? Presumably, but just what/how?... The default is now the new function `split-window-sensibly' which has been split off from `window--try-to-split-window'. > I think I'll wait and see the new code and doc, before trying to figure out the > behavior. > >> >> > If that's not true, then (besides fixing the doc), how can >> >> > `split-window-preferred-function' prevent window splitting >> >> > altogether? >> >> >> >> With the new code by always returning nil. >> > >> > OK. I guess I'll need to try the new behavior, after your >> > recent changes, before trying to fix my code to make use of >> > the new `display-buffer'. >> >> There won't be any substantial change but the one mentioned above, so >> you can try it already with the current code. > > The current (pretest) code has `split-window-preferred-function' = nil. If that > won't be nil, then with what default-value function would I replace it, in order > to "try it" (the new behavior)? `split-window-sensibly'. martin