bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 29 Nov 2012 10:19:53 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com
> 
> On 11/28/2012 09:59 PM, Eli Zaretskii wrote:
> 
> > Let me turn the table and ask why should we insist on this assertion?
> > What do we gain by enforcing it?
> >
> > I know what we lose: the trunk is severely broken for 2 days, and
> > counting.  3 people have independently bumped into this in 2 different
> > situations.  If there's no significant gain in this, I say let's
> > remove the assertion and move on.
> 
> OK for now. But I still thinks that we just ignore some unusual cases
> which needs more investigations.

I'm okay with investigating, as long as others don't suffer too much.

For starters, can you tell what triggered the assertion violation in
Juanma's case?  IOW, how did we wind up in a situation where (AFAIU)
the selected window displays a buffer other than the current one?

And Drew, could you please try coming up with a simple recipe starting
with "emacs -Q"?  If you define a configuration with a minibuffer-less
frame, a separate minibuffer frame, and arrange for *Completions* to
pop up yet another frame, then trigger completion in some simple way,
does Emacs abort like in your original report?

TIA