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

[Carlos Pita]

(Sorry if it ends up being a dup but I'm resending this because I'd
previously sent it with an attached screencast and it seems that it's
not being accepted by the bug tracker. In any case, it was the wrong
cast :P. Please let me know if there's a policy wrt screencasts,
even the right ones. I think it could be useful in this case but it's
not that important.)

Hi,

Here is one more example that tries to capture the essence of another
popup dialog in org that is giving me headaches. It's fixed by
applying Martin's patch, it's not "fixed" with the
redisplay-before-fit workaround (although the redisplay does make a
difference as shown below) and it's "fixed" with the
redisplay-after-creation workaround.
1) I run emacs -q and execute this simple code that opens a window
with 30 numbers, each in its own line:

(progn
  (switch-to-buffer-other-window "popup")
  (erase-buffer)
  (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n"))
  (fit-window-to-buffer))

The window properly fits the numbers, which are all visible  (please
ensure your screen and frame is large enough). Now I close the window
and make the modeline bigger as in Jonas' example:

(setq-default
 mode-line-format
 (cons (propertize " " 'display
                   (create-image "/* XPM */ static char * image[] = {
\"3 60 1 1\",
\"0 c #00aaff\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\",
\"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\"
};" 'xpm t :ascent 'center))
       mode-line-format))

2) If I run the code above one more time, that is:

(progn
  (switch-to-buffer-other-window "popup")
  (erase-buffer)
  (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n"))
  (fit-window-to-buffer))

The numbers are only partially visible, the window looks as if I had
scrolled the buffer down to the bottom. Scrolling up it's easy to see
that not all of the numbers fit the window. I guess this is expected
because of the miscalculations regarding the modeline height.

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.

Best regards,
Carlos