Subject: bug#7728: 24.0.50; GDB backtrace from abort

From: Eli Zaretskii <[email-masked]>
Date: Tue, 11 Jan 2011 23:14:26 +0200

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked], [email-masked]
> Date: Tue, 11 Jan 2011 15:55:12 -0500
> 
> 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.

Probably because of minibuffer-only frames or something.

Perhaps Drew could publish the relevant parts of the window
configuration that was being restored in that case (or any other
similar case).

> > 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?

I don't think it matters much, since if we don't have a window to work
with, we are only guesstimating anyway.

> >  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.

Yes, something like that.