bug#38828: 26.3; Customized mode line breaks height of vertical scroll bar

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 38828@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 3 Jan 2020 10:38:46 +0100
> 
>  > You can see at the end of frame.el we have a list of variables we
>  > watch that have nothing to do with debugging.
> 
> I noticed that in the meantime.  So we could easily add, for example,
> 'scroll-bar-width' to that list and simplify text like the following
> 
>       If you do not specify a window’s scroll bar settings via
>    ‘set-window-scroll-bars’, the buffer-local variables
>    ‘vertical-scroll-bar’, ‘horizontal-scroll-bar’, ‘scroll-bar-width’ and
>    ‘scroll-bar-height’ in the buffer being displayed control the window’s
>    scroll bars.  The function ‘set-window-buffer’ examines these variables.
>    If you change them in a buffer that is already visible in a window, you
>    can make the window take note of the new values by calling
>    ‘set-window-buffer’ specifying the same buffer that is already
>    displayed.
> 
> in the Elisp manual?

Yes, I think so.  You can easily try that yourself, though.

> I wonder why Fset_buffer_redisplay apparently doesn't have to call
> bset_redisplay to redisplay_other_windows.  What am I missing here?

Probably the fact that prevent_redisplay_optimizations_p is stronger
than windows_or_buffers_changed?

>  > Glyph matrices don't care about the pixel size of the window,
> 
> ... but when the pixel height grows we may have to allocate new glyph
> rows too, I suppose ...

Yes.

>  > they
>  > only care about the maximum number of glyph rows they can
>  > accommodate.  So increasing the size of a mode line has the effect of
>  > making the window's glyph matrices use fewer rows (assuming the
>  > window's pixel size doesn't change).  In addition, a GUI window
>  > usually has a matrix allocated for more rows than it actually uses,
>  > which is why each matrix has both 'nrows' and 'rows_allocated'
>  > members, and the former is likely to be smaller than the latter.  When
>  > a window's resize
> 
> ... where a "resize" includes changes of its buffer's default face
> font, line spacing, the mode line height ...

Right.

>  > But I now think that we need to reset the mode_line_p flag even if we
>  > reallocate, because the rows which existed before reallocation are
>  > copied to the enlarged matrix, so that flag is kept.  So I think I
>  > will install the patch with that small change.
> 
> Works fine now.

Thanks.