bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize

[martin rudalics <rudalics@gmx.at>]

 > You are
 > our window-management czar:

A carpenter, at best.

 > No, by arranging the buffer contents and letting redisplay do its
 > job.  Problems of this kind happen only when a mode changes buffer
 > contents and related data structures (such as properties and overlays)
 > in response to redisplay, something that is bad idea to begin with,
 > because at the very least it immediately triggers another redisplay
 > cycle, and kills many redisplay optimizations.

‘follow-mode’, to stick to one of the examples I cited earlier, uses
neither properties nor overlays.  It must, however, know the exact
‘window-end’ position of any window that could be followed by another.
This also means that a correct implementation of ‘follow-mode’ should be
allowed to specify the order in which windows are redisplayed.  So
ideally, redisplay would be able to process each window separately, tell
us its new start and end positions and allow modes to react properly.

 > IMO, lack of infrastructure is not an excuse for bad design.  Either
 > the missing infrastructure should be added, or the design changed (if
 > possible) to some better-behaving alternative.  In extreme cases, the
 > whole idea should be dropped as unworkable.

I'm convinced that the current version of ‘linum-mode’ doesn't behave
well and line numbers should be calculated and written by the display
engine.  But I'm too lazy to do that (probably because I don't use line
numbers myself).

 > As an option, perhaps.  And it should be opt-in IMO, because most use
 > cases shouldn't care about automatic resizing such as this one.

So let's provide an option for this.

martin