From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: selected-frame and selected-window Date: Sun, 09 Dec 2012 05:50:38 +0200 Message-ID: <83ip8bdgtt.fsf@gnu.org> References: <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <83ip90w48g.fsf@gnu.org> <4AB1E6AB8BB448AAB037D70CBECBFD9D@us.oracle.com> <83d2z8w2na.fsf@gnu.org> <837gpgvz81.fsf@gnu.org> <83txrwloiz.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1355025059 31586 80.91.229.3 (9 Dec 2012 03:50:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Dec 2012 03:50:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 09 04:51:12 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ThXv2-0007Jj-SR for ged-emacs-devel@m.gmane.org; Sun, 09 Dec 2012 04:51:08 +0100 Original-Received: from localhost ([::1]:52768 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThXuq-00014k-Gh for ged-emacs-devel@m.gmane.org; Sat, 08 Dec 2012 22:50:56 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThXun-00014U-PV for emacs-devel@gnu.org; Sat, 08 Dec 2012 22:50:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ThXum-0005YA-Lu for emacs-devel@gnu.org; Sat, 08 Dec 2012 22:50:53 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:55278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThXum-0005Y3-AU for emacs-devel@gnu.org; Sat, 08 Dec 2012 22:50:52 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MEQ00E00VR5B100@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sun, 09 Dec 2012 05:50:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEQ00DU6W0QPCA0@a-mtaout21.012.net.il>; Sun, 09 Dec 2012 05:50:51 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155392 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Sat, 08 Dec 2012 18:51:40 -0500 > > >> > This is assertion violation in redisplay_internal, here: > >> > eassert (EQ (XFRAME (selected_frame)->selected_window, > >> > selected_window)); > >> > This crash is probably of the kind you reported in the past, related > >> > to the selected-frame/selected-window issues. > >> I'm not sure is that assertion is actually right. > > Well, "bzr annotate" says you added it ;-) > > Should we just go ahead and remove it? Inaccurate assertions are a > > maintenance headache, to say nothing of user aggravation. > > The rest of my message mentioned reasons why the equality is > sometimes broken. Yes, I know. But a broken assertion is a candidate for removal, IMO. > Now, I tend to consider that those cases should be considered bugs, > because IIRC there are cases where we do rely on this equality. If you or someone else can describe those cases, we could use that knowledge to modify the assertion or fix the bugs which violate it. > More specifically, I added such easserts in an effort to track the > origin of an error. We are evidently unable to do that in a long time. All we do is cause user aggravation and add to maintenance load. > But to fix these bugs we need to figure out how to handle the "mode-line > :eval" case. Do you have any practical suggestions for that?