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: Wed, 06 May 2009 18:21:26 +0200 Message-ID: <4A01B906.1020605@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> 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 1241627889 27423 80.91.229.12 (6 May 2009 16:38:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 May 2009 16:38:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 06 18:37:59 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 1M1k86-0005br-1c for ged-emacs-devel@m.gmane.org; Wed, 06 May 2009 18:37:58 +0200 Original-Received: from localhost ([127.0.0.1]:55821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1k85-0005k6-6q for ged-emacs-devel@m.gmane.org; Wed, 06 May 2009 12:37:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1k81-0005jH-7Q for emacs-devel@gnu.org; Wed, 06 May 2009 12:37:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1k7v-0005io-Ip for emacs-devel@gnu.org; Wed, 06 May 2009 12:37:51 -0400 Original-Received: from [199.232.76.173] (port=41583 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1k7v-0005il-GJ for emacs-devel@gnu.org; Wed, 06 May 2009 12:37:47 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:43607) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1M1k7u-00005o-QP for emacs-devel@gnu.org; Wed, 06 May 2009 12:37:47 -0400 Original-Received: (qmail invoked by alias); 06 May 2009 16:37:43 -0000 Original-Received: from 62-47-42-255.adsl.highway.telekom.at (EHLO [62.47.42.255]) [62.47.42.255] by mail.gmx.net (mp061) with SMTP; 06 May 2009 18:37:43 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/n5RB54o/n9WwPz9Is8unLCN9L/w1VDMp5HfroTH qt2cWsE5x7JPaa User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <002d01c9cdbe$e51356e0$0200a8c0@us.oracle.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 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:110731 Archived-At: > Right. So the real question is how will it be explained? My point was that there > should be no need to refer to Emacs 22. You asked why Emacs 23 behaves differently, so I tried to explain its behavior in terms of what I understand about the behavior of Emacs 22. >> 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. 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. >> If that call fails to provide a suitable window, it gets called >> again with the least recently used window > > On the same frame, presumably (?). Yes. >> 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. >> a suitable window, `display-buffer' will use an existing one to >> display its buffer. > > It will display the buffer in an existing window? The previous doc string said > that it will split a window to do the displaying. Which doc-string? An unconditional phrase like "it will split a window" should not appear anywhere in the text. >> > The doc string says that if `split-window-preferred-function' >> > returns nil both times, then `display-buffer' splits the >> > window that respects the values of `split-height-threshold' >> > and `split-width-threshold'. >> > >> > What if more than one window respects those values? Among >> > which windows does `display-buffer' choose, and how does it >> > choose one of them, if more than one respects those values? >> > And what does it do if no window respects those values? >> > This info is missing, AFAICT. >> >> It usually says "tries to split" so if the window can't be split it >> won't be split. > > I don't follow. I don't think that answers any of those questions. I didn't understand your questions. In any case bear in mind that `display-buffer' _tries_ to split a window. If it cannot split a window for whatever reason it doesn't split it. The manual states all reasons why a window cannot be split. >> > It sounds as if no matter how >> > `split-window-preferred-function' is defined, >> > `display-buffer' will split a window. Is that correct? >> >> No. 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. >> 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. >> > 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. martin