GNU bug report logs - #13007
24.3.50; emacs_backtrace.txt

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 13007 <at> debbugs.gnu.org, lekktu <at> gmail.com, drew.adams <at> oracle.com
Subject: bug#13007: 24.3.50; emacs_backtrace.txt
Date: Thu, 29 Nov 2012 18:46:43 +0200

> Date: Thu, 29 Nov 2012 10:19:53 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: 13007 <at> debbugs.gnu.org, lekktu <at> gmail.com, drew.adams <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.