Re: bug in 23.2.92 with anything

[martin rudalics <rudalics@gmx.at>]

 >>>>  >     /* When running redisplay, we play a bit fast-and-loose and allow e.g.
 >>>>  >        selected_frame and selected_window to be temporarily out-of-sync so
 >>>>  >        when we come back here via `goto retry', we need to resync because we
 >>>>  >        may need to run Elisp code (via prepare_menu_bars).  */
 >>>>  >     select_frame_for_redisplay (old_frame);
 >>>>  >
 >>>>  > It would be good to get rid of such risky code.
 >>>>
 >>>> Is there any reason why this should not select the window too?
 >>> By "this" you mean what?  IOW, who or what should "select the window
 >>> too"?
 >> This code.  That is, select_frame_for_redisplay.
 >
 > What would be the utility of doing so?  The redisplay will next call
 > redisplay_windows, which walks the entire window tree and redisplays
 > each one of them (temporarily selecting its buffer in the process).
 > How would selecting the frame's selected window help anything in this
 > procedure?  I won't expect selected_window to play any significant
 > role in the redisplay process, because it redraws all windows.

I don't know enough about redisplay.  IIUC select_frame_for_redisplay is
used mainly to set up frame local variables for displaying all buffers
shown in that frame.  In display_mode_lines selected window and selected
frame are both temporarily deselected but in update_tool_bar only the
selected frame is deselected (just as in select_frame_for_redisplay).

If code is run in between, the fact that the selected window is not on
the selected frame might be surprising.  But I don't know what any code
run by update_tool_bar or redisplay_internal really needs in this
context.  So if you say it doesn't matter I take your word for it.

martin