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

[martin rudalics <rudalics@gmx.at>]

 > 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?  I wonder why Fset_buffer_redisplay apparently
doesn't have to call bset_redisplay to redisplay_other_windows.  What
am I missing here?

 > 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 ...

 > 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 ...

 > needs less rows that 'rows_allocated', there's no
 > reallocation, just a change in the 'nrows' field.
 >
 > 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, martin