[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#38828: 26.3; Customized mode line breaks height of vertical scroll bar
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]