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: Mon, 4 May 2009 10:13:48 -0700 Message-ID: <000e01c9ccdb$b0997180$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> 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 1241457266 26056 80.91.229.12 (4 May 2009 17:14:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 May 2009 17:14:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'martin rudalics'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 04 19:14:16 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 1M11k5-0000UJ-G0 for ged-emacs-devel@m.gmane.org; Mon, 04 May 2009 19:14:13 +0200 Original-Received: from localhost ([127.0.0.1]:40746 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M11k4-0007m7-Eo for ged-emacs-devel@m.gmane.org; Mon, 04 May 2009 13:14:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M11jx-0007jX-Bt for emacs-devel@gnu.org; Mon, 04 May 2009 13:14:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M11js-0007fJ-4V for emacs-devel@gnu.org; Mon, 04 May 2009 13:14:04 -0400 Original-Received: from [199.232.76.173] (port=36221 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M11jr-0007fE-Hu for emacs-devel@gnu.org; Mon, 04 May 2009 13:13:59 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:32461) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M11jr-00046j-2k for emacs-devel@gnu.org; Mon, 04 May 2009 13:13:59 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n44HE42M022870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 May 2009 17:14:06 GMT Original-Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n44HDoGO002798; Mon, 4 May 2009 17:13:50 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 May 2009 10:13:48 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49FF1AA0.9080601@gmx.at> Thread-Index: AcnM15qR6USaDWBCT4+nkF6BD4K6HgAAH2Ug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: abhmt007.oracle.com [141.146.116.16] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010201.49FF224D.00E5,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:110644 Archived-At: > > Emacs adding DWIM now means that if you want the simple, > > straightforward behavior of old you need to write it yourself? > > It's not about adding DWIM. Let's have a look at "the simple, > straightforward behavior of old": You apparently have a frame with two > side-by-side windows and `pop-up-frames' bound to nil (IIRC > `pop-up-frames' is usually non-nil on your Emacs). The left window is > the larger one and the right window the least recently used one. > > Emacs 22 first tries to split the larger (left) window and fails to do > so because the window is not full-width. Then Emacs tries to split the > least recently used (right) one and succeeds. I suppose you were not > aware of this Correct; I was not aware of the details behind the Emacs 22 "magic", as Stefan put it. Thanks for the explanation. > since otherwise you wouldn't have written (in your first > mail on this subject) "the problem seems to be that display-buffer now > tries to split the largest window" where "now" apparently means "Emacs > 23". The difference is that with Emacs 23 `display-buffer' tries to > split the largest window _and_ succeeds in doing so. Thanks for that explanation also. You might consider mentioning that change in the NEWS (in those terms or similar terms) - your call. 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)? 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). > So basically you wrote some code that (1) relied on some undocumented > behavior of `display-buffer', Yes, I mentioned that. Because the behavior was undocumented, it was magic, and more or less take-it-or-leave-it. Replacing it with different magic is OK, but let's document that, so the magic trick is exposed. And let's provide simple ways to control the behavior, other than `define-your-own'. > 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. > > You are not making it easier for users (which includes > > Emacs-Lisp users)... > > The present code is more fully documented. So I hopefully made it > easier for users (which includes Emacs-Lisp users) to complain ... That's good. Maybe there are still a few things that could be explained? My questions above are a start. Martin, I do appreciate the work you've done wrt behavior involving windows, BTW, as I think you know. Much of that work has in fact been clearing up and taming existing magical, take-it-or-leave-it behavior. I'm thinking, for instance, of the work you did around quitting help and view mode.