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: Wed, 6 May 2009 10:54:15 -0700 Message-ID: <006501c9ce73$abde6710$c2b22382@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> <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> 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 1241632565 12567 80.91.229.12 (6 May 2009 17:56:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 May 2009 17:56:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'martin rudalics'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 06 19:55:55 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 1M1lLW-00049q-Gc for ged-emacs-devel@m.gmane.org; Wed, 06 May 2009 19:55:55 +0200 Original-Received: from localhost ([127.0.0.1]:49431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1lLV-0005zc-RK for ged-emacs-devel@m.gmane.org; Wed, 06 May 2009 13:55:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1lK7-0004cd-Ap for emacs-devel@gnu.org; Wed, 06 May 2009 13:54:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1lK2-0004ab-Bh for emacs-devel@gnu.org; Wed, 06 May 2009 13:54:26 -0400 Original-Received: from [199.232.76.173] (port=49907 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1lK2-0004aW-79 for emacs-devel@gnu.org; Wed, 06 May 2009 13:54:22 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:59043) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M1lK1-0006Uv-FF for emacs-devel@gnu.org; Wed, 06 May 2009 13:54:21 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n46Hs9ad021419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 May 2009 17:54:10 GMT Original-Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n46HsF83017547; Wed, 6 May 2009 17:54:16 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 May 2009 10:54:13 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A01B906.1020605@gmx.at> Thread-Index: AcnOaRU9IWY+OxsrTxyOFNiN+SktCAAAHgpA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010207.4A01CEC6.018F: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:110734 Archived-At: > >> If you set this to any other function, bear in mind that it may > >> be called two times: The argument of the first call is the > >> largest window on its frame. > > > > But which frame is used? How, if at all, does that > > unspecified frame relate to the `display-buffer' FRAME arg? > > Did you ever read section 28.8 of the Elisp manual? It gives you a > step-by-step operative description of how `display-buffer' finds a > window to split and how it tries to split it. 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. 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. 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). > The various doc-strings cannot provide that information since I > would have to repeat the entire process of how to find a window > for splitting over and over for each > variable and function involved. That's fine. The doc strings can point to the doc. But the doc itself is not very clear, to me. You know the code. You have in mind just "how `display-buffer' finds a window to split and how it tries to split it", but I don't see that explained, and I don't understand it. Call me dense, if you like. > >> as argument. If neither of these calls produces > > > > "returns" would be better than "produces". It is the > > return value that is examined. > > But usually a new window is created first. Sounds like you want to argue. Just trying to help. I think "returns" is more helpful here, but use whatever wording you like. BTW, I realize now that I misread the doc string for `split-window-preferred-function'. It says that if the option value is nil..., and I misread that as saying that if the option value is a function that returns nil both times it is called by `display-buffer'... Trying to understand the doc string while reading the code, I mixed things up. > >> There's no window splitting when `pop-up-windows' is > >> nil. Usually there's no window splitting either when both > >> `split-height-threshold' and `split-width-threshold' are nil, > > > > Is that stated somewhere? > > In the manual. 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. (The description of `split-width-threshold' is, however, clear.) > >> With the new code any splitting will be done exclusively by > >> `split-window-preferred-function'. > > > > Ah, OK. That would explain the doc string change from saying that > > `display-buffer' will split to saying that it will display > > in an existing window (see above). Is the new behavior you > > describe in the pretest code, or in a later bug fix? > > The only user visible change will be that you cannot specify nil as > value of `split-window-preferred-function'. I'll commit that in a > couple of days. So `split-window-preferred-function' is now always a function? That would seem to change quite a lot. 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'? 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?... 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)? I'll just wait and see what this is all about. It's too difficult to follow at this point. If my feedback helps, fine; if not, ignore.