bug#38181: Actual height of mode-line not taken into account

[martin rudalics]

> 3) Now I add a redisplay before the fit:
>
> (progn
>    (switch-to-buffer-other-window "popup")
>    (erase-buffer)
>    (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n"))
>    (redisplay t)
>    (fit-window-to-buffer))
>
> Again, only about half of the numbers are visible and the window looks
> as if its buffer has been scrolled down. But now by scrolling up I can
> check that all the numbers fit the window. So the height of the window
> is right but there is that unnecessary scrolling down of the contents.
>
> 4) Now I repeat with the forced redisplay even earlier:
>
> (progn
>    (switch-to-buffer-other-window "popup")
>    (redisplay t)
>    (erase-buffer)
>    (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n"))
>    (fit-window-to-buffer))
>
> This seems to work around the issue.
>
> I believe that in 3 there is some miscalculation during the insertion
> of text into the buffer that forces a scroll, but I'm having a hard
> time trying to explain that. Anyway, it's another case the
> redisplay-before-fit advice can't cope with.

In (3) the redisplay happens _after_ the insertion so redisplay may have
to scroll the buffer to make point, which is at its maximum, visible.
The subsequent 'fit-window-to-buffer' and the final implicit redisplay
won't change the window's start position after that.  If the window
after the split were large enough to encompass 30 lines, this won't
happen.

In (4) the redisplay happens _before_ the insertion so erasing the
buffer will set 'window-start' to 'point-min' and the implicit redisplay
at the end will see point within the visible portion and not change
'window-start'.

martin