GNU bug report logs - #38181
Actual height of mode-line not taken into account

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 38181 <at> debbugs.gnu.org
Subject: bug#38181: Actual height of mode-line not taken into account
Date: Sat, 16 Nov 2019 17:59:21 +0200

> From: Jonas Bernoulli <jonas <at> bernoul.li>
> Cc: 38181 <at> debbugs.gnu.org
> Date: Sat, 16 Nov 2019 15:54:53 +0100
> 
> > If this is to make the mode line prettier, then it should be done
> > once, at the beginning of a session, right?  In that case, why calling
> > redisplay after loading the package or enabling a feature is not a
> > solution?
> 
> No that won't work.  Each buffer has its own mode-line so when
> a new buffer is created, then its height has to be calculated.

Ouch!

> In practice all mode-lines have the same height, so if Emacs could
> use the height "that all the other buffers/windows are using" when
> it does not know the actual height, then that would help.

fit-window-to-buffer doesn't use (or know, really) the height of the
mode line in the scenario you presented.  Instead, it gets the height
of the window's text area (which excludes the mode line and the header
line) from the data stored in the window object.  The problem is that
this data is recalculated only when the window is redisplayed, so
without the call to 'redisplay' we use stale data until the next
redisplay cycle.

However, if all the mode lines have the same height, then the problem
shouldn't have happened, and so now I wonder what am I missing.  If
you simulate the situation where the mode line changes, while keeping
its height (even if that height is unusually large), does the problem
with fit-window-to-buffer still happen?

Previous Next

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