bug#7728: 24.0.50; GDB backtrace from abort

[Stefan Monnier]

> My conclusion after studying this is that everything that happens
> below Fselect_frame is reasonable: we switch to the frame and redraw
> the cursor in all of its windows.  In particular,
> update_cursor_in_window_tree simply walks the entire window tree of
> the newly selected frame.  I don't see how we can avoid any of this
> when selected_window is nil, because selected_window has nothing to do
> with the windows that are being processed.  None of these functions
> even references selected_window, which is TRT.

Yes, I see that as well, now.

> The first place that does reference selected_window is the
> CURRENT_MODE_LINE_HEIGHT macro used in window_text_bottom_y, and that
> leads to the abort.

There's still one thing I don't understand: why do we call
Fselect_frame?  AFAICT, Fset_window_configuration has no reason to
select a new frame, it all works within the selected-frame.

> So I see 2 ways to prevent this particular problem:
>  1) Handle the case of selected_window == Qnil in
>     CURRENT_MODE_LINE_FACE_ID.

But should it always return the mode-line-inactive face here, or should
it always return the mode-line face?

>  2) Change the code of Fset_window_configuration and Fselect_window,
>     to have some other way of preventing the latter from storing point
>     in the old selected window, without setting selected_window to
>     nil.

That sounds like a better solution.  E.g. move the code of
Fselect_window to another function, add a third argument to it
specifying whether to swap-out point in selected_window, and make
Fset_window_configuration call that new internal function.

But maybe Fselect_frame should simply not be run in this case.


        Stefan