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: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, 38181 <at> debbugs.gnu.org
Subject: bug#38181: Actual height of mode-line not taken into account
Date: Sun, 17 Nov 2019 19:16:32 +0100

> I'd prefer a hook, because the problem probably isn't limited to
> fit-window-to-buffer.

The display engine has to be able to ultimately control the behavior
to avoid ending up in an infinite loop.  Hooks are dangerous (though
evaluating the mode line can be dangerous too IIRC).

> Wait, don't we already call window-size-change-functions in this case?
> If not, would it help if we did?

That's precisely what I would like to avoid.  Note that we do not
re-run window change functions when they, for example, change the size
of a window.  Such changes are, in a sense, lost to the next redisplay
cycle.

>> display_mode_lines sets refit_window_to_buffer to 2 provided it is 1
>> and the mode line height of this window has changed.
>
> The detection of the change in mode-line height is outside
> display_mode_lines, see the snippet I posted up-thread.

Right.  It should be done there.

>> The display engine eventually calls 'fit-window-to-buffer' for all
>> windows that have refit_window_to_buffer equal 2 and sets it to 3.
>
> We need to figure out the "eventually" part.  It should happen after
> the windows have their dimensions updated due to the mode-line
> changes.  Do you know where this happens?

Nowhere, hopefully.  Managing the mode-line happens in the display
engine only.  Note that a function like 'window-text-height', for
example, detracts the mode line, header line and now even the tab line
heights on-the-fly from the stored pixel_height and might even use
estimate_mode_line_height.  The stored text_height _does_ include mode
and header line.

>> This might be tricky for windows stored in configurations and states.
>
> Why tricky?  A stored configuration shouldn't be affected by any
> changes after it's tored, no?

When we restore a configuration we probably should nullify the
bit-field to avoid unwanted re-runs.  Or not nullify to ensure
re-runs?

> Mmm... actually, it could be that we cannot resize windows during
> redisplay at all.  See, for example, how resize_mini_window does its
> tricky job.  We may need to call this outside of redisplay.

Inherently, resize_mini_window does what 'fit-window-to-buffer' does
and it gets called from redisplay_internal.

martin

Previous Next

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