[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#410: 23.0.60; display-buffer regression

From: Stephen Berman
Subject: bug#410: 23.0.60; display-buffer regression
Date: Sat, 14 Jun 2008 00:04:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

In GNU Emacs (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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]