> Thanks, but is there any reason to remove the call before updating the
 > tool bar?  You see, I believe one of the reasons for the need to
 > clear_garbaged_frames is that call you suggest to remove.  Why not
 > leave it there, and _add_ one more call after prepare_menu_bars (and
 > perhaps condition it on the same condition as prepare_menu_bars)?

We can obviously do that (see attached patch).  But is there any reason
we cannot run the

   do_pending_window_change (true);
   clear_garbaged_frames ();

_after_ the

       prepare_menu_bars ();
       do_pending_window_change (true);

block?

In either case, the more I look into this, the more things confuse me.
For example, why does

	  if (!must_finish)
	    {
	      do_pending_window_change (true);
	      /* If selected_window changed, redisplay again.  */
	      if (WINDOWP (selected_window)
		  && (w = XWINDOW (selected_window)) != sw)
		goto retry;

not check for windows_or_buffers_changed too just as we do after the
third do_pending_window_change call?  But then I don't understand why we
check for windows_or_buffers_changed at all.  adjust_frame_size doesn't
set that IIUC but it does garbage the frame - why don't we check that in
redisplay_internal?

 >> While frame resizing can make the
 >> selected window small, it will neither remove nor change it.
 >
 > Never-ever?

Never-ever.  Fdelete_window_internal, Fdelete_other_windows_internal and
Fset_window_configuration are the only functions allowed to delete
windows.  run_window_change_functions could delete the selected window
so we probably should do the w == sw check after that now.

martin