bug#7728: 24.0.50; GDB backtrace from abort

[martin rudalics]

>> I doubt it's kosher because if the old selected window is not on the
>> restored frame and a window on the restored frame gets selected, the
>> point of the buffer whose window is deselected is not stored in the old
>> selected window's pointm which is certainly not TRT.
>
> But I bet Drew's code works just fine, when it does not crash.

I doubt the scenario sketched above shows up frequently.  And when it
show up I doubt many people would notice it.

> Anyway, if switching away of the frame inside save-window-excursion is
> not allowed, we should detect that and signal an error.

It _is_ allowed by design.

> That would
> solve this bug cleanly, with no need for any low-level hacking or
> kludges.

Have you looked into the ChangeLog of this?  It was never clean and
people just managed to make it work, more or less.

As I noticed earlier, one bug is in the design of using two variables
that should never change independently from each other.  Better, there
should be only one variable - either selected_window or selected_frame.
After that has been solved we would have to fix the bug where the
selected window is not the selected window because it's on a frame that
has not been risen.  And, finally we should warn people to avoid things
like `save-window-excursion' in the first place.

>> To avoid the present crash we could try something like the attached
>> patch (which does not try to solve anything but that crash).
>
> But if you say that switching a frame inside save-window-excursion is
> not supported, why do we need to change code to support it?  What am I
> missing?

As I said it is allowed.  But almost all 100 or so occurrences of
`save-window-excursion' in Emacs are harmful.  Take, for example, the
commented-out sections of buff-menu.el.  Richard took them out
apparently because he used that code in practice and noticed that it
didn't DTRT.  Most other instances are still here because people don't
care enough.

martin