Re: bug in 23.2.92 with anything

[martin rudalics]

>>>>  >     /* 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