bug#19576: write-file writes the wrong buffer

[Alan Mackenzie]

Hello, Eli.

On Wed, Nov 18, 2015 at 07:45:03PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 17 Nov 2015 20:02:04 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: 19576@debbugs.gnu.org

[ .... ]

> > I propose the following strategy to fix the bug:

> > 1. Call resize_mini_window from redisplay_internal before the call to
> >   prepare_menu_bars.
> > 2. Remove the call to resize_mini_window from display_echo_area_1, and
> >   make that function of type void.
> > 3. Change the contract of echo_area_display, such that the echo area
> >   must have been set to the correct height before calling it.
> > 4. Adapt message3_nolog (the only other function which calls
> >   echo_area_display) to call resize_mini_window.

> > As a result of these changes, any change in the size of the echo area
> > would be taken into account when invoking window-size-change-functions.

> I must say I prefer to avoid changes in the processing order of the
> display engine, unless they are absolutely necessary and we understand
> very well the effect of the order change.  Which IMO is not the case
> here.

Yes.  This thought occurred to me too, this morning.  I identified the
function calls which were "missing" before doing the echo area size
change that I inserted.  These were (in order):

    1. reconsider_clip_changes
    2. bset_update_mode_line
    3. clear_garbaged_frames
    4. inhibit_garbage_collection
    5. forget_escape_and_glyphless_faces

.  Why not duplicate some of these calls on the way to the new echo area
size change code?  1. I don't know what "clip_changes" are.  2. is
surely harmless if done twice.  3. doesn't seem connected with the
purpose of the function, but surely is expensive enough only to be done
once.  4. seems like a good idea anyway, and 5. is cheap, and may have
some effect upon the calculation of the new size of the echo area.

> 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.

Also, there may be a possibility of w-s-c-f being invoked twice in a
single redisplay action.  I don't know whether this is bad or not, but
it doesn't seem good.

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.

> Martin, is there any reason why window_resize_apply doesn't set the
> frame's window_sizes_changed flag, but instead relies on its callers
> to do that?

[ patch tested and snipped ]

-- 
Alan Mackenzie (Nuremberg, Germany).