From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#3366: 23.0.94; doc of split-window-preferred-function, display-buffer, etc. Date: Tue, 26 May 2009 11:28:57 +0200 Message-ID: <4A1BB659.30003@gmx.at> References: <7BFD115BD21E4677AAB801DA5EBBFED1@us.oracle.com> <4A1A42F9.7050500@gmx.at> <779632281BA742BFB5A1470D08B17538@us.oracle.com> Reply-To: martin rudalics , 3366@emacsbugs.donarmstrong.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 1243331511 9330 80.91.229.12 (26 May 2009 09:51:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 May 2009 09:51:51 +0000 (UTC) Cc: 3366@emacsbugs.donarmstrong.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 26 11:51:44 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M8tJv-0002WI-Vp for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 May 2009 11:51:44 +0200 Original-Received: from localhost ([127.0.0.1]:53165 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8tJv-0004Xr-Ac for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 May 2009 05:51:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M8tHf-0002hV-3J for bug-gnu-emacs@gnu.org; Tue, 26 May 2009 05:49:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M8tHa-0002fL-Jn for bug-gnu-emacs@gnu.org; Tue, 26 May 2009 05:49:21 -0400 Original-Received: from [199.232.76.173] (port=57739 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8tHZ-0002fC-05 for bug-gnu-emacs@gnu.org; Tue, 26 May 2009 05:49:17 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:53137) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M8tHX-0004bK-Iz for bug-gnu-emacs@gnu.org; Tue, 26 May 2009 05:49:16 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4Q9nBlJ004830; Tue, 26 May 2009 02:49:13 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n4Q9Z658002662; Tue, 26 May 2009 02:35:06 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 26 May 2009 09:35:06 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3366 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3366-submit@emacsbugs.donarmstrong.com id=B3366.12433301521718 (code B ref 3366); Tue, 26 May 2009 09:35:06 +0000 Original-Received: (at 3366) by emacsbugs.donarmstrong.com; 26 May 2009 09:29:12 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n4Q9T6DF001710 for <3366@emacsbugs.donarmstrong.com>; Tue, 26 May 2009 02:29:07 -0700 Original-Received: (qmail invoked by alias); 26 May 2009 09:29:00 -0000 Original-Received: from 62-47-49-49.adsl.highway.telekom.at (EHLO [62.47.49.49]) [62.47.49.49] by mail.gmx.net (mp011) with SMTP; 26 May 2009 11:29:00 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19zlUxo66ZzcRxeRU75lFwRoL2wHL5LfsKyh8hBIw EyoXICORgwC7qN User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 26 May 2009 05:49:21 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:28188 Archived-At: > We're talking about `display-buffer', which is a function that provides > no guarantee about where the window gets displayed, so code that uses it > should be prepared for surprises. If you argue that code should have > more control over it, I agree. IMHO `display-buffer' has to follow (a) changes in display technology and (b) user preferences. (a) implies that code cannot rely upon which window gets split or how that window is split accross future versions of Emacs. (b) implies that code using `display-buffer' must be aware of user preferences. If coders want precise control, they should use `set-window-buffer'. > I suggested changing the `not-this-window' argument so it can have > a description of the recommended window to use (not a specific window, > but something that could specify whether it should be on the same-frame > or not, in an adjacent window or not, in a preferably tall/wide window, > in a window close to the minibuffer, ...). The `not-this-window' argument should be used with caution because it already now overrides user preferences wrt to `display-buffer'. I think that only if the user does not specify any preference in `pop-up-frames' or `pop-up-windows', an application should be allowed to override that. So we should enhance the semantics of these variables first. In addition, I think `window-size-fixed' should be handled the way we treat dedicated windows. That is, when this is non-nil for a particular window, it should inhibit that `display-buffer' splits that window. But only the value `t' should inhibit that the window can be resized manually. Thus an application can set `window-size-fixed' to some non-nil, non-t value to avoid that the window gets split and/or resized by `display-buffer'. Also `display-buffer' should call `split-window-preferred-function' at most once. Calling it with the largest and the LRU window (which may designate one and the same window) appears merely disconcerting. martin