From unknown Mon Aug 18 18:04:16 2025 X-Loop: don@donarmstrong.com Subject: bug#410: 23.0.60; display-buffer regression Reply-To: Stephen Berman , 410@debbugs.gnu.org Resent-From: Stephen Berman Original-Sender: steve@escher.local.home Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 13 Jun 2008 22:10:06 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 410 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12133946783991 (code B ref -1); Fri, 13 Jun 2008 22:10:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-4.5 required=4.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 13 Jun 2008 22:04:38 +0000 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 m5DM4YRi003985 for ; Fri, 13 Jun 2008 15:04:35 -0700 Received: from mail.gnu.org ([199.232.76.166]:42142 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1K7HLp-00071Z-G0 for emacs-pretest-bug@gnu.org; Fri, 13 Jun 2008 18:02:29 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1K7HNl-0003cj-TT for emacs-pretest-bug@gnu.org; Fri, 13 Jun 2008 18:04:34 -0400 Received: from mail.gmx.net ([213.165.64.20]:56140) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1K7HNl-0003cG-Cc for emacs-pretest-bug@gnu.org; Fri, 13 Jun 2008 18:04:29 -0400 Received: (qmail invoked by alias); 13 Jun 2008 22:04:26 -0000 Received: from i5387E13F.versanet.de (EHLO escher.local.home) [83.135.225.63] by mail.gmx.net (mp041) with SMTP; 14 Jun 2008 00:04:26 +0200 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX19csXYxUetcWbYdW1mWj59RhZCuzr0HRASSRfIcp5 9CFrWLU9MbFmuM Received: by escher.local.home (Postfix, from userid 1000) id C07581D0E7B; Sat, 14 Jun 2008 00:04:25 +0200 (CEST) From: Stephen Berman To: emacs-pretest-bug@gnu.org Sender: steve@escher.local.home Date: Sat, 14 Jun 2008 00:04:25 +0200 Message-ID: <873anhkn4m.fsf@escher.local.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2008-06-13 on escher 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. 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. (I wanted to step through the code with gdb but for some reason gdb failed to halt execution in the right source file, so I could not pursue this.) Steve Berman From unknown Mon Aug 18 18:04:16 2025 X-Loop: don@donarmstrong.com Subject: bug#410: 23.0.60; display-buffer regression Reply-To: martin rudalics , 410@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.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: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.121343649114704 (code B ref -1); Sat, 14 Jun 2008 09:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.8 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 14 Jun 2008 09:41:31 +0000 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 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 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 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 Received: (qmail invoked by alias); 14 Jun 2008 09:41:20 -0000 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 Message-ID: <4853920E.9020106@gmx.at> Date: Sat, 14 Jun 2008 11:40:30 +0200 From: martin rudalics User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Stephen Berman , 410@debbugs.gnu.org CC: emacs-pretest-bug@gnu.org References: <873anhkn4m.fsf@escher.local.home> In-Reply-To: <873anhkn4m.fsf@escher.local.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-CrossAssassin-Score: 2 > 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 From unknown Mon Aug 18 18:04:16 2025 X-Loop: don@donarmstrong.com Subject: bug#410: 23.0.60; display-buffer regression Reply-To: Stephen Berman , 410@debbugs.gnu.org Resent-From: Stephen Berman Original-Sender: news Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 14 Jun 2008 22:45: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: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.121348292312003 (code B ref -1); Sat, 14 Jun 2008 22:45:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.6 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 14 Jun 2008 22:35:23 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5EMZHrs011997 for ; Sat, 14 Jun 2008 15:35:19 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7eL7-0001IJ-5q for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 18:35:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7eL5-0001Hv-W1 for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 18:35:16 -0400 Received: from [199.232.76.173] (port=38398 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7eL5-0001Hm-K6 for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 18:35:15 -0400 Received: from main.gmane.org ([80.91.229.2]:51012 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K7eL5-0000XI-9G for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 18:35:15 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K7eKy-0000fW-7b for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2008 22:35:08 +0000 Received: from i5387e512.versanet.de ([83.135.229.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Jun 2008 22:35:08 +0000 Received: from stephen.berman by i5387e512.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Jun 2008 22:35:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Stephen Berman Date: Sun, 15 Jun 2008 00:34:47 +0200 Lines: 45 Message-ID: <874p7vfxx4.fsf@escher.local.home> References: <873anhkn4m.fsf@escher.local.home> <4853920E.9020106@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: i5387e512.versanet.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Sender: news Cc: emacs-pretest-bug@gnu.org X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) On Sat, 14 Jun 2008 11:40:30 +0200 martin rudalics wrote: >> 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. Thanks for the explication, I didn't grasp that in my cursory perusal. > I've tried to restore the original behavior. Please > try again. Your patch makes display-buffer work as it previously did in cases like the above; thanks. Steve Berman