all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 38828@debbugs.gnu.org
Subject: bug#38828: 26.3; Customized mode line breaks height of vertical scroll bar
Date: Thu, 02 Jan 2020 21:58:49 +0200	[thread overview]
Message-ID: <83v9ptiq9y.fsf@gnu.org> (raw)
In-Reply-To: <bf7e1bed-a33f-4770-07e1-8f9afeb8f067@gmx.at> (message from martin rudalics on Thu, 2 Jan 2020 20:19:05 +0100)

> Cc: 38828@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 2 Jan 2020 20:19:05 +0100
> 
>  > There's more than one problem here (didn't you wonder why pressing F3
>  > doesn't immediately redraw the mode line?).
> 
> It never did that unless I changed the size of some window too, so why
> should I have wondered?

Well, because if you don't do anything after F3, the mode line stays
without update forever.

> How expensive is watching a variable?

Just an extra 'if' in a few places where we set the variable, to check
if it's being watched.  Grep the sources for SYMBOL_TRAPPED_WRITE.

> So far I was convinced this would be used for debugging purposes only.

You can see at the end of frame.el we have a list of variables we
watch that have nothing to do with debugging.

> What does "resizing a window without allocating new rows" encompass?
> Is this only shrinking the window height ('shrink-/split-window') or
> also making a special line like the mode line taller (eating away some
> of the remaining matrix lines, naively spoken)?

Glyph matrices don't care about the pixel size of the window, 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 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.





  reply	other threads:[~2020-01-02 19:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31  9:57 bug#38828: 26.3; Customized mode line breaks height of vertical scroll bar martin rudalics
2019-12-31 16:05 ` martin rudalics
2020-01-01 16:10 ` Eli Zaretskii
2020-01-01 17:49   ` martin rudalics
2020-01-02 14:15     ` Eli Zaretskii
2020-01-02 19:19       ` martin rudalics
2020-01-02 19:58         ` Eli Zaretskii [this message]
2020-01-03  7:31           ` Eli Zaretskii
2020-01-03  9:38           ` martin rudalics
2020-01-03 10:19             ` Eli Zaretskii
2020-01-03 10:43               ` martin rudalics
2020-01-03 13:07                 ` Eli Zaretskii
2020-01-03 15:57                   ` martin rudalics
2020-01-03 16:08                     ` Eli Zaretskii
2020-01-03 16:34                       ` martin rudalics
2020-01-03 17:11                         ` Eli Zaretskii
2020-01-03 16:30                     ` Eli Zaretskii
2020-01-03 17:16                       ` martin rudalics
2020-01-04 19:36                       ` Amin Bandali
2020-01-04 19:43                         ` Eli Zaretskii
2020-01-04 20:25                           ` Amin Bandali

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83v9ptiq9y.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=38828@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.