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

[Eli Zaretskii]

> Cc: jonas@bernoul.li, 38181@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 16 Nov 2019 20:28:10 +0100
> 
>  > What are the frequent calls?  Help and completions windows come to
>  > mind, but those are interactive, and so I'm not sure I see why calling
>  > redisplay would be a bad idea there.  Are there other callers which
>  > I'm missing?
> 
> The functions for displaying temporary buffers when
> 'temp-buffer-resize-mode' is on.  I do not think that the overhead for
> calculating the mode line height is excessive.  It's just that IIUC
> even Jonas changes the mode line height only once per window/buffer
> assignment so even for him this overhead is practically always lost.

But I thought we'd established that mode-line height calculation is
not the culprit, the culprit is the fact that a window's height is not
recomputed when the mode-line height changes.  Did I misunderstand?

>  >> Right.  But that same program could also redisplay all windows in
>  >> these cases, right?
>  >
>  > I meant that calling redisplay should do this automatically.
> 
> By calculating the mode line before drawing the scroll bars?

No, by triggering redrawing of scroll bars when we detect that the
mode line changed its height.  In this place of redisplay_window:

      display_mode_lines (w);

      /* If mode line height has changed, arrange for a thorough
         immediate redisplay using the correct mode line height.  */
      if (window_wants_mode_line (w)
          && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
        {
          f->fonts_changed = true;
          w->mode_line_height = -1;
          MATRIX_MODE_LINE_ROW (w->current_matrix)->height
            = DESIRED_MODE_LINE_HEIGHT (w);
        }

Or maybe in redisplay_internal, when we see that f->fonts_changed is
set.