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

[Eli Zaretskii]

> Date: Tue, 25 Aug 2015 09:25:10 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: pipcet@gmail.com, 21333@debbugs.gnu.org

Before I respond to your comments, let me just clarify that what I say
about this should not be interpreted as a veto of some kind.  You are
our window-management czar: if you think my objections should be
overruled, by all means go ahead and make the changes.

> >> Naively spoken it's obvious that when you shrink the minibuffer you show
> >> more lines in the window above and ‘linum-mode’ has to add numbers for
> >> those lines.  And when you enlarge the minibuffer, ‘follow-mode’ will
> >> lose some lines at the bottom of the left window and has to show them at
> >> the top of the right window.
> >
> > In well-behaved modes this happens automatically, as part of
> > redisplay.
> 
> Via ‘pre-redisplay-function’?

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.

> >> Maybe they use the ‘post-command-hook’ function instead.
> >
> > Of course, they do!  The flag of bad design.
> 
> IIUC they didn't have another choice before ‘pre-redisplay-function’ was
> added.

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.

> >> This is, in fact, an abuse of ‘set-window-configuration’.  But how fix
> >> it?  We'd need a hook, say ‘window-size-change-functions’, that tracks,
> >> among other things, whether a window was resized due to a change of the
> >> minibuffer height and, if that happens, set a flag to indicate that the
> >> window configuration must be restored.
> >
> > I'd say, don't set the "size changed" flag unless the size really
> > changed.
> 
> Sure.  Nevertheless we would have to also track changes due to automatic
> minibuffer resizing.

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.

> Alternatively, Fset_window_configuration could run a modified version of
> ‘compare-window-configurations’ to compare the current configuration
> with the one to be restored and restore the old configuration iff these
> differ.  I'm not sure whether this would be any cheaper, especially when
> the configuration does change frequently.

As I said too many times in this thread, performance is the last thing
I care about in this respect.