GNU bug report logs - #38828
26.3; Customized mode line breaks height of vertical scroll bar

Previous Next

Package: emacs;

Reported by: martin rudalics <rudalics <at> gmx.at>

Date: Tue, 31 Dec 2019 09:59:01 UTC

Severity: normal

Found in version 26.3

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38828 <at> debbugs.gnu.org
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
  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





This bug report was last modified 5 years and 199 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.