bug#410: 23.0.60; display-buffer regression

[Stephen Berman <stephen.berman@gmx.net>]

On Sat, 14 Jun 2008 11:40:30 +0200 martin rudalics <rudalics@gmx.at> 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