From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#410: 23.0.60; display-buffer regression Date: Sat, 14 Jun 2008 11:40:30 +0200 Message-ID: <4853920E.9020106@gmx.at> References: <873anhkn4m.fsf@escher.local.home> Reply-To: martin rudalics , 410@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 1213438052 18395 80.91.229.12 (14 Jun 2008 10:07:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2008 10:07:32 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: Stephen Berman , 410@emacsbugs.donarmstrong.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 14 12:08:15 2008 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 1K7Sg8-0001lI-SK for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Jun 2008 12:08:13 +0200 Original-Received: from localhost ([127.0.0.1]:52133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7SfI-00061i-Ky for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Jun 2008 06:07:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7SfD-0005zM-E4 for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 06:07:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7SfB-0005w0-FM for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 06:07:14 -0400 Original-Received: from [199.232.76.173] (port=56812 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7SfB-0005vh-9X for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 06:07:13 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:39854) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K7SfA-0002tC-4Z for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 06:07:13 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5EA77bt021298; Sat, 14 Jun 2008 03:07:08 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m5E9o3dw015935; Sat, 14 Jun 2008 02:50:03 -0700 X-Loop: don@donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 14 Jun 2008 09:50:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 410 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by submit@emacsbugs.donarmstrong.com id=B.121343649114704 (code B ref -1); Sat, 14 Jun 2008 09:50:03 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 14 Jun 2008 09:41:31 +0000 Original-Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5E9fRGc014693 for ; Sat, 14 Jun 2008 02:41:29 -0700 Original-Received: from mx10.gnu.org ([199.232.76.166]:48391) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1K7SED-0002dc-N5 for emacs-pretest-bug@gnu.org; Sat, 14 Jun 2008 05:39:21 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1K7SGA-0008FS-Fm for emacs-pretest-bug@gnu.org; Sat, 14 Jun 2008 05:41:26 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:34510) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1K7SG9-0008FA-U6 for emacs-pretest-bug@gnu.org; Sat, 14 Jun 2008 05:41:22 -0400 Original-Received: (qmail invoked by alias); 14 Jun 2008 09:41:20 -0000 Original-Received: from 62-47-44-151.adsl.highway.telekom.at (EHLO [62.47.44.151]) [62.47.44.151] by mail.gmx.net (mp015) with SMTP; 14 Jun 2008 11:41:20 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/BdkJ6H4/BknUaFW3jdRovUuWozqAdMNYTWr06SC 6hUgNWFGjlKVCQ User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <873anhkn4m.fsf@escher.local.home> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-CrossAssassin-Score: 2 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Sat, 14 Jun 2008 06:07:14 -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:18383 gmane.emacs.pretest.bugs:22631 Archived-At: > The recent reimplementation of display-buffer in lisp resulted in the > following changed behavior, which I consider a regression: > > 1. emacs -Q > > 2. M-x calendar > ==> The window is vertically split, the *scratch* buffer above and > the Calendar buffer is below in a smaller window sized to fit. > > 3. M-: (pop-to-buffer (get-buffer "*Messages*")) > ==> Now the *Messages* buffer is above and the Calendar buffer is > still below, but the windows are evenly split, i.e. the Calendar > window is no longer sized to fit but is too big. Prior to the > reimplementation of display-buffer doing this step did not change the > height of the Calendar window. > > The behavior in step 3 results from the invocation of > window--even-window-heights in the last clause of the cond in > display-buffer, which happens because the *Messages* buffer exits but is > not displayed. If the sexp in step 3 contained *scratch* instead of > *Messages*, the height of the Calendar window would not have changed. Thanks for noticing this. > Looking at the pre-reimplementation source of Fdisplay_buffer, it looks > like the window heights should get evened out just as in the lisp > reimplementation; nevertheless, this is not what happens in the above > recipe with the older code. It's because in the Elisp code I evened window heights whenever they were not equal. The original code evened heights only when the height of the window to display BUFFER-OR-NAME was less than that of the selected window. I've tried to restore the original behavior. Please try again. I'd like to make the window code resilient in a way that applications like calendar can naturally set `window-size-fixed'. As a consequence, `display-buffer' wouldn't change the calendar window's size even it were larger than the new window. Setting `window-size-fixed' can currently result in unexpected behavior. Fixing this is non-trivial. Also I'd like to give `split-height-threshold' and `window-min-height' buffer-local semantics and maybe add a `window-max-height' variable so to do `fit-window-to-buffer' and `shrink-window-if-larger-than-buffer' implicitly during each window configuration change. `window-min-height' equalling `window-max-height' for a particular buffer would then imply `window-size-fixed' for that buffer. Eventually, a user should be able to change window configurations arbitrarily with the calendar window always keeping its original size (unless there's no other way, obviously). martin