From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: xassert in dispextern.h Date: Tue, 01 Mar 2005 23:02:50 +0100 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109714724 32001 80.91.229.2 (1 Mar 2005 22:05:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Mar 2005 22:05:24 +0000 (UTC) Cc: emacs-devel@gnu.org, Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 01 23:05:24 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D6FTn-00053y-Hg for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2005 23:04:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6FmQ-0008QB-WB for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2005 17:23:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D6FjB-0006nM-AX for emacs-devel@gnu.org; Tue, 01 Mar 2005 17:20:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D6Fiz-0006h0-U8 for emacs-devel@gnu.org; Tue, 01 Mar 2005 17:20:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6Fix-0006ef-4O for emacs-devel@gnu.org; Tue, 01 Mar 2005 17:20:15 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D6FS7-0007a3-N6 for emacs-devel@gnu.org; Tue, 01 Mar 2005 17:02:51 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D6FS7-0002AU-5C; Tue, 01 Mar 2005 17:02:51 -0500 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Tue, 01 Mar 2005 22:16:27 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:34008 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34008 storm@cua.dk (Kim F. Storm) writes: > Jason Rumney writes: >> >> What's completely backwards is to turn off a feature that helps us >> find bugs so that people can treat the CVS HEAD as a stable release >> of Emacs. > > I agree with David that the benefits from the xasserts do not > justify the costs at this stage of development. IIRC, even 21.1 was > released without having xasserts defined by default during pretest. The problem with assertions is that they are usually are put in because of a particular suspicion. Then the stuff gets tested, and the suspicion confirmed or not. That is the most active life time of an assertion. After that, it mainly remains for what amounts to regression testing purposes: making sure that one does not reintroduce old bugs. But that usually can be done by checking just occasionally with assertions enabled, in particular if old problems resurface. With the kind of display crashes I had recently, the only way to debug this is to make a test case. We currently have some situations where using the line movement or scrolling commands does not make progress. This is a bit of a nuisance. Only a few of those cases now cause crashes due to xasserts. But the cases causing crashes in no way are more important than the others. This is shifting priorities in the wrong way: the behavior of Emacs-21.4 in that regard was _much_ worse than what we have now. Crashes make a problem top priority, and the crashes that I had did not make sense: the problem was known and accessible even before the crashes, and is in Kim's ballpark, more or less. It is important, but not necessarily release-critical. If one movement command in some special situation does not make progress, it is easy enough to use another one. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum