bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Eli Zaretskii]

> Date: Mon, 08 Nov 2010 11:07:04 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: Jakub Turski <yacoob@gmail.com>, 7348@debbugs.gnu.org
> 
>  > The call to do_pending_window_change at line 11397 in xdisp.c
>  > (emacs-23 branch) seems to change selected_window because of the
>  > following call chain, but the variable `w' in redisplay_internal still
>  > points to the old selected window.
>  >
>  >   redisplay_internal
>  >     -> do_pending_window_change
>  >       -> change_frame_size
>  >         -> change_frame_size_1
>  >           -> set_window_height
>  >             -> size_window
>  >               -> delete_window (/* Delete WINDOW if it's too small.  */)
> 
> That's bad.  So basing redisplay_internal entirely on
> 
>    struct window *w = XWINDOW (selected_window);
> 
> is inherently broken.  But simply reassigning
> 
>     w = XWINDOW (selected_window);
> 
> after every do_pending_window_change call is hairy since it changes the
> selected window under our feet, so any things done for the window that
> was selected before the call would probably have to be redone for the
> now selected window.

The only thing I see that uses selected_window and is done between
this line:

  ++redisplaying_p;

and the 1st call to do_pending_window_change is this call:

  reconsider_clip_changes (w, current_buffer);

We could simply call reconsider_clip_changes again if we detect that
the selected_window changed after the call to do_pending_window_change.

The second call to do_pending_window_change is conditioned on
must_finish being zero, which I think cannot happen when this
situation hits.

And the third call to do_pending_window_change already goes back to
retry anyway.

So maybe there's no problem in updating the value of w in this case.