bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)

[martin rudalics]

> The information flow is
> unidirectional: the functions which change the windows should tell
> what they changed, and redisplay will then decide what that requires.
> For example, if some windows changed their dimensions, redisplay would
> need to know which dimension changed.

The window code should have all necessary information at hand (but for
the final height of the mode lines) when redisplay starts but would have
to know what redisplay wants it to tell.  It would be easy to reserve
one bit on each window to tell that its width, left scroll bar, left
margin, left fringe, body width, right fringe, right margin, right
scroll bar or the height, header, tab, mode line, body and scroll bar
height changed.  And one bit for each of font, line spacing, start and
point position and the scrolling statuses of the window.  Maybe also one
bit for the left and top edge within the frame and the left and top body
edge of the window.

Once it has been established what redisplay wants to know, it would be
easy to transfer practically all notifications currently performed by
frame.c to window.c.  That is, gui_set_left_fringe would no longer
SET_FRAME_GARBAGED because the window code would decide whether the
width of any left fringe of any window affected should really change and
set the left_fringe_width_changed, the body_width_changed and maybe also
the left_body_edge_changed bit accordingly.

In addition there would probably be one window_changed bit per window to
tell redisplay that one of the bits above changed and one frame_changed
bit to tell redisplay that at least one window has its window_changed
bit set.  Then we probably should try to remove any special treatment of
the selected window in this regard, since with all our excursions, code
can never tell anyway which window will be the selected one at the time
redisplay starts.

Finally, redisplay would have to merge in all buffer text and position
changes for each window showing that buffer mostly as it does now and
separately consider a few frame changes like visibility.

Information flow would still be bidirectional for the mode lines: As
soon as redisplay has calculated their respective heights and these
should change (a rare case), the window code would have to be informed
about that, store the new heights, adjust the body height, recalculate
scroll bar dimensions and leave it to redisplay to decide whether to
calculate mode line heights again to avoid infinite recursion.

martin