bug#19576: write-file writes the wrong buffer

[Eli Zaretskii]

> Date: Wed, 18 Nov 2015 23:23:04 +0000
> Cc: martin rudalics <rudalics@gmx.at>, juri@linkov.net, andlind@gmail.com,
>   19576@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Could you try a simpler patch below?  It seems to fix both your test
> > case and the one originally reported in bug#21333.
> 
> It does indeed fix my test case (I haven't tried it on #21333).  However
> it violates the specification of window-size-change-functions, which
> says that the hook is called _before_ redisplay, not after it has
> started.  I suppose one could argue over what "redisplay" means here,
> but intuitively I would say it is the putting of glyphs into matrices.

"Redisplay" is indeed not defined well enough, but the only reasonable
interpretation of "before redisplay" is that it happens before the
call to redisplay_internal.  And this is false for your suggested
solution as well.  It is false even by your definition, because
prepare_menu_bars already manipulates the glyph matrices, the ones it
creates for the tool bar (and also menu bar on some display types).
And display_echo_area also manipulates glyph matrices (it calls
try_window).

Which is only logical for an event that by itself is triggered as part
of redisplay!  It's redisplay that decides to resize the mini-window,
so calling the hook after that decision _cannot_ possibly count as
being "before redisplay".

IOW, once we, by popular demand, decided to call
window-size-change-functions when the mini-window is resized, we
invalidated that specification.  All the other callers of this hook
are not part of a redisplay cycle, but this one is, and cannot be
anywhere else.

So no matter what change we eventually install, the documentation of
the hook needs to be amended to say that it's called "before redisplay
or at the beginning of a redisplay cycle", and maybe also mention that
the second case is when the mini-window is resized.

(Btw, the ELisp manual wisely doesn't say "before redisplay", only the
doc string does.)

> Also, there may be a possibility of w-s-c-f being invoked twice in a
> single redisplay action.

How do you see that as a possibility?  For that to happen, the flag
indicating that the mini-window was resized should be already set for
that window when we enter redisplay, but I don't see how that could
happen, and still lead to an additional resize as part of redisplay.

I also don't think it's a catastrophe if this hook is called more than
once in some rare situations.

> One way to "solve" these problems, although it is not pretty, is to put
> an invocation of w-s-c-f into display_echo_area_1, just after the echo area
> has (possibly) been resized.  This invocation would also test and reset
> FRAME_WINDOW_SIZES_CHANGED (f).   There would have to be further
> invocation(?s) of w-s-c-f in the other arms of the pertinent conditional in
> redisplay_internal.  For that pain, we could take the w-s-c-f out of
> prepare_menu_bars.

I don't see the need for such complications, certainly not on the
release branch.

Thanks.