bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#38181: Actual height of mode-line not taken into account


From: Carlos Pita
Subject: bug#38181: Actual height of mode-line not taken into account
Date: Sat, 16 Oct 2021 15:00:51 -0300

Hi Martin, thank you for the commentary.

> What is the "workaround"?  IIUC there is no "redisplay" one can call on
> a "per buffer" base.

The one I linked above which some packages have been using for almost
a couple of years now and, indeed, was mentioned early in this thread
but never questioned AFAICS, namely:

(defvar-local moody--size-hacked-p nil)

(defun moody-redisplay (&optional _force &rest _ignored)
  (when (and mode-line-format (not moody--size-hacked-p))
    (setq moody--size-hacked-p t)
    (redisplay t)))

(advice-add 'fit-window-to-buffer :before #'moody-redisplay)

The problem I see with it is that buffers often survive their windows
and are later reused in other windows. This happens with some of the
popups that fit to their buffers we are talking about. Moreover, using
a window parameter instead of the buffer local won't be enough,
because sometimes fit-window-to-buffer is called from another window
(I mean, not the popup window) after the excursion that prepares the
popup, so the redisplay ends up running in the wrong window.

> Even the 'redisplay' trick will not be sufficient: Consider Eli's
> scenario in this thread but with _different_ heights for active and
> inactive mode lines.  It will break things when after doing the
> 'fit-window-to-buffer' call you (de-)select the window you've just fit.

I think I follow the argument but I don't see it as having practical
interest for the use cases that motivated this report. All modeline
customizations I'm aware of use a single modeline height, although the
modeline contents and faces may of course change with major and minor
modes and activity status.

>  > changing a modeline on the fly is not a likely event, would it be
>  > so bad to trigger that early redisplay on window creation?
>
> I think you mean with every set_window_buffer?  And probably with every
> set_window_configuration too.  Did you try it?

I still need to refine my concept of "on window creation". When you say
"with evert set_window_buffer" I'm not sure whether you mean something
like:

1. There is an event (a) of window creation and later and event (b)
when the buffer is set for the new window. So if I call redisplay
immediately after (a) it would be too early because the modeline won't
be properly set up until (b).

Or, instead, something like:

2. Windows often change buffers and buffers may have modeline formats
that imply different modeline heights.

If 1 is the case then sure, maybe it's a different event that I need
to listen to, but it's still one forced early redisplay per window.
But if you mean 2, again I don't see the relevance in practice.

With regard to set_window_configuration similar observations can be done.

> change of a buffer local variable like 'mode-line-format'.  So basically
> no redisplay is ever needed in the first place, just a recalculation of
> the mode line heights of all windows whose heights have changed.

This is good to know.

Thank you again.

Best regards,
Carlos





reply via email to

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