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

[Jonas Bernoulli]

>> Could fit-window-to-buffer invoke
>> 'redisplay' internally, perhaps?
>
> It could but it's called way too often to warrant such behavior by
> default.  But we could give it a separate optional argument so users
> can avoid the advice.  I think Jonas could easily write and a test a
> patch along this idea.

Again, the mode-line-prettifiers are not the ones who create new buffers
and then call fit-buffer-to-window.  It's arbitrary other packages that
do that.  An optional argument therefore would not help because when one
of the prettifier modes is active, then each and every third-party
caller of fit-buffer-to-window would have to pass that optional
argument.

This is the advice I currently use:

(defvar-local moody--size-hacked-p nil)

(defun moody-redisplay (&optional _force &rest _ignored)
  (unless moody--size-hacked-p
    (setq moody--size-hacked-p t)
    (redisplay t)))

(advice-add 'fit-window-to-buffer :before #'moody-redisplay)

Of course fit-buffer-to-window itself could be changed to do that and it
could also be taught to only do so iff the user opted in to doing it.

----

Creating and displaying a new buffer and creating and resizing a new
window surely *already* causes a "redisplay" without the programmer
having to explicitly call `redisplay'.  So if we explicitly tell
fit-window-to-buffer to redisplay, then that means that we are
redisplaying twice, right?

I am under the impression (but this is just wild speculation) that
redisplay only performs some of the necessary size calculations before
doing the actual redisplaying.  But some other calculations (including
those concerning the mode-lien) are done only after the actual
redisplaying has already happened.  That is too late for this redisplay
round but causes the values to be in place for all subsequent
redisplays.  So the fix could be to do the mode-line based calculations
earlier?