bug#7728: 24.0.50; GDB backtrace from abort

[Drew Adams]

> > And just what code do you suggest for going off to do something on
> > a different frame and returning?  AFAIK we do not have
> > a `save-frame-excursion'.
> 
> Hmm... let's see... how 'bout `with-selected-frame'?  ;-)

Does not exist before Emacs 23, for one thing.  My code needs to work with
multiple Emacs versions.  And please do not suggest that I add such macros to
older versions just to be able to work around a newly introduced Emacs bug.  And
please do not suggest that I split the code to use the macro only for Emacs
23.3+ since this is a new bug (regression).

> > I have always considered (and seen) `save-window-excursion' 
> > to be the way to do this.
> 
> No, as Martin mentioned, save-window-excursion is the macro to use if
> you want to write code that breaks in "odd" cases (sidenote:
> one-buffer-per-frame is one of those "odd" cases that tend to trigger
> bugs in code using save-window-excursion, so you probably 
> "often" suffer from those things, like me).

Sorry, but I have never, ever suffered from "those things".  And
`save-window-excursion' _has_ always been used for this kind of thing in Emacs
AFAIK - revisionism notwithstanding.

In the case in question, the selected window and selected frame happen to be the
_same_ as the destination window and frame (they are the minibuffer window and
standalone frame).

In this case the `save-window-excursion' should amount to a no-op in the end.
The source and target window and frame need not be the same in general, but they
are the same in the crashes I reported.  If Emacs cannot save and restore
without crashing in this case then Houston you really have a problem.

Look - you know that you lost your car keys in the park, but because it's
nighttime you decide to look for them in the living room.  That's silly.

* Let me repeat that the _source code works fine_ - no error, no crash, no bug.

* Let me repeat too that the byte-compiled code (no matter which Emacs version
it was compiled with) works fine in all Emacs versions except the current
development code - no error, no crash, no bug.

This is not a source-code problem.  It is not a byte-code problem.

This is a _regression_ due to some change in the development version that no
longer plays well with the byte-compiled code.  Please investigate that
interaction: dev version + byte code.  Your keys are in the park.

Advice to change my source code so as to not use `save-window-excursion' is
misplaced wrt this bug.  It amounts to blaming the victim.  You are looking
under the lamp in the living room, but your keys are lying in the park
somewhere.

This is a problem with the byte code only - that is, the problem is with how the
byte-code is handled by the latest dev code.  No problem with Emacs 23.2 or even
with dev code prior to when I filed the bug (exact date of regression unknown).

You lost your keys in the park.  Please do not ask me to move the couch in the
living room.  Whether my code could or should be improved in some way is
orthogonal to fixing this Emacs bug.

This is a regression.  Emacs should handle the byte-code correctly, as it has
always done before - and as it still correctly interprets the source code.