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

[martin rudalics]

>>   > 2. redisplay fit redisplay fit redisplay ...
>
>> Sorry.  I still don't understand the purpose of the last redisplay here.
>
> It's not the last, it's a repeating sequence, I left the dangling
> redisplay instead of ending it in a fit because I was explaining my
> unfortunate choice of words when I said "after", but it's formally the
> same, the point being that the first redisplay is not enough.

OK.  Can we settle on something like

2. redisplay fit redisplay fit redisplay ... fit

Bear with me but I'm trying to simultaneously understand what you are
doing and what Emacs is doing.  This is multitasking and I'm bad at
that.

>> Does
>>
>> 2. redisplay fit redisplay fit ...
>>
>> fail?  What are the values returned by 'window-mode-line-height' after
>> each redisplay?
>
> As far as I can see this works,

What is "this" here?

> as I said before. In the example
> provided by Jonas window-mode-line-height is 29 immediately after
> calling set-face-attribute, but after setting mode-line-format it's
> always 60, no matter if I call redisplay or fit or none of them or in
> what order. But even if the reported height is the same, the layout is
> not, omitting the (previous) redisplay always crops the text.

I'm currently not even sure what we are comparing here.  Let's settle on
the following idioms:

(defun selected-window-mode-line-height ()
  (pos-visible-in-window-p t nil t)
  (window-mode-line-height))

(let ((val (selected-window-mode-line-height)))
  (fit-window-to-buffer)
  (cons (selected-window-mode-line-height) val))

Do you see any change in the return value here?  And when you run this
repeatedly as in the

redisplay fit redisplay fit redisplay ... fit

scenario?  And with 'set-face-attribute' and setting 'mode-line-format'
intermingled?  Maybe Emacs sometimes doesn't cache the result of an
earlier call of display_mode_line although it could (or should).

martin