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

[martin rudalics <rudalics@gmx.at>]

 > Well, any relevant window hook in [1] is advertised as "called during
 > redisplay", so that surely isn't the place to trigger that same
 > redisplay to begin with...

Roughly spoken, redisplay calculates the height of the minibuffer window
and those of the mode lines and, if any of these changed since last
redisplay, does another redisplay in the hope that they stick to their
values now.  After that, it runs the hooks you mention above so these
can take the now final (wrt redisplay) window and mode line sizes into
account.

A function on any of these hooks that changes a mode line height or a
window size does that on its own risk.  It's _not_ recommended.

 > Let's go back to advising then. Here are some questions I have:
 >
 > 1. Is there a primitive function that is like the mother of all
 > windows?

I always wanted to write one to make 'display-buffer' simpler but nobody
was enthusiastic about it.

 > There is no window-create nor create-window alikes, so maybe
 > split-window-internal?
 >
 >      > Window creation means 'split-window' which assigns the new window a
 >      > buffer that appears in the window that was split.
 >
 >      So this more or less settles the question, but to be more precise:
 >      do you see any difference of relevance between advicing split-window
 >      and split-window-internal?

Never advise an internal function or one with an '-internal' postfix.
Such function may change or be removed at any time.

 > 2. Or is it better to advise set-window-buffer/configuration for
 > whatever reasons? Any or both of them?

Both.  Especially because you may want to reuse a window for showing
another buffer in it.

 > 3. If advising set-window-buffer/configuration is the preferred
 > method, I'm still assuming that we will keep a window parameter in
 > order to disable the forced redisplay after its first execution for the
 > window. Is there any reason not do so (taking into account what
 > I said before of the target use case: a single modeline height for
 > every modeline during the entire session).

The mode line height is window specific, taking into account what the
buffer, the window and the window's frame have set up for it.

 >       > Or do the mode lines of _all_ your windows have
 >       > the same height?  That indeed would simplify things a lot.
 >
 >       Yes, this is by far the usual case and I believe it's a fact that
 >       favours the "advise window creation" strategy over the
 >       "advise window buffer/config change events" (with or without
 >       the "just once per window" clause) strategy.

In one of my earlier postings I falsely assumed that we _could_ retrieve
the prospective heights of mode lines by calling
'pos-visible-in-window-p' followed by 'window-mode-line-height',
forgetting that the former restores the previous values after doing its
calculations.  By looking at these functions you could derive a new one
that calculates mode line heights in a similar way and peruse the return
values of that function in 'window-text-pixel-size' in the hope that
they won't change with the next redisplay.  The 'mode-lines' argument of
'window-text-pixel-size' should then accept a value like 'update' to
reflect this special use case.  It might be worth the experience.

martin