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: Wed, 02 Mar 2005 01:52:02 +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 1109725470 6406 80.91.229.2 (2 Mar 2005 01:04:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2005 01:04:30 +0000 (UTC) Cc: Jason Rumney , snogglethorpe@gmail.com, emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 02 02:04:29 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D6IHm-0002We-BX for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2005 02:04:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6IaR-0004iJ-B3 for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2005 20:23:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D6IZr-0004Tj-Fa for emacs-devel@gnu.org; Tue, 01 Mar 2005 20:23:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D6IZl-0004QX-5L for emacs-devel@gnu.org; Tue, 01 Mar 2005 20:22:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6IZk-0004Nf-D6 for emacs-devel@gnu.org; Tue, 01 Mar 2005 20:22:56 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D6I5t-00036o-Fq for emacs-devel@gnu.org; Tue, 01 Mar 2005 19:52:05 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D6I5r-0007g6-PW; Tue, 01 Mar 2005 19:52:04 -0500 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Wed, 02 Mar 2005 00:14:40 +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:34023 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34023 storm@cua.dk (Kim F. Storm) writes: > Miles Bader writes: > >> [I should note that the thing which caused me to originally enable >> xassert by default is that it caught (I always have it enabled) a case >> where iterator stacks could overflow -- something that otherwise would >> just result in rare, hard to debug, memory corruption.] > > That's right -- it was a mistake I had made a few days earlier -- > not some tricky old bu[g] that took hours of debugging to realize > that it was just a silly test... But Miles says himself that he has enabled xassert by default always, so for Miles it would not have made a difference. > I'll suggest that we leave the xassert in there for 2 more weeks -- > just in case something serious pops up -- and then remove them again > and focus on finishing the release. I just want to add a bit of rationale why I am arguing this so heatedly. We all know that the last release has been away eternities (2001 was 21.1 IIRC). Our current code base offers a much extended modern platform support concerning fonts/colors/etc (Windows, Gtk+, Carbon). The menus have been improved and made much more user-friendly, lots of problems have been fixed, filling is improved, Unicode handling, also with other applications, is getting tolerably and so on and so on. There are a lot of features that people need, and after all this time it does not make sense to tell them "Forget it. This software is not for you." We don't have the resources to maintain a "for-the-users" branch right now. People are lessening the impact of that by providing ready-made compilations of CVS Emacs on several platforms. There are "versions" for MacOSX, Debian GNU/Linux, Windows. Those versions take pressure off our back and give us leeway for getting Emacs into release state. I find it acceptable if I tell people "We don't have the time to work on anything but preparing the release. But in the meantime, you can try HEAD. It is as good as you can get right now, unless there is some unexpected regression. You get no warranty, not even a bad conscience if things break for you. But we'll share with you what we have." For that reason, I'd like to keep HEAD in a _reasonable_ state as long as this does not in any manner impact our work. It has by now grown into the equivalent of a covert betatest. We, as developers, have the means to turn on some testing options when somebody asks on the list for pinpointing a particular problem. No problem with that. But others, that provide the packaging of the best we can offer, don't have that kind of knowledge. CVS Emacsen are by now not rare to find in the wild, and that is a good thing since it provides us with valuable feedback, and it also makes people less impatient, and it gives them a view about what to expect. I am holding talks and workshops about Emacs: at the end of the week at the GNU/Linux Tagung in Chemnitz (second largest of that kind in Germany) where I am also holding the keynote address about creativity and the impact of intellectual property laws. A key aspect in that address (that is not Emacs-related) is the pride of the creator, and the willingness to share. I feel acute embarrassment when I have to tell people that we don't care about sharing our efforts and would them rather not be able to make any use of our work right now. My second talk at that conference _will_ be about Emacs, and how it ties with packages (of which I am partly maintainer) into a bedrock of desktop. I'll showcase the stuff. Again, telling people that they stand no chance of downloading anything that works satisfactorily like showcased because we willingly have made the code unusable for all but developers, would be an embarrassment. After that I am at the EuroTeX2005, a joint conference of the national French and German TeX user groups, where Donald Knuth and Hermann Zapf will be guests of honor. Apart from two talks, I'll be holding a workshop for using and installing Emacs. Because of several features, performance and bug fixes, the visual appeal and the default setup, I will be doing the workshop with CVS versions and handing out information and handholding for walking people through what will at one time more or less become the more common way of installing and configuring Emacs 22.1. Again, it will be acutely embarrassing to tell them a) that they need to tamper with the code if they want to compile themselves. b) that they need not expect precompiled Emacsen be in a usable state since our default HEAD is not sound intentionally. If we can get rid of the xassert setting right now (so that I need not mention it in the workshop) instead of in two weeks, I promise to be running my own Emacs copy with the xasserts on for at least 6 weeks after the conferences. While this helps only with the GTK+ port, it will be qualified and hopefully debugged bug reports (_if_ bugs are found by me) instead of "Emacs crashes for me". I am making a living with selling TeX solutions as free software, and I want to be able to make Emacs an integral part of my offerings. And if I can't revert to compilations/snapshots prepared by anybody else, it will be near impossible for me to offer stuff based on Emacs under Windows and Carbon. I have no sensible other options under Windows: Emacs 21.4 does not offer images in buffers, and that's essential even if I were to forget about all other shortcomings. XEmacs-21.4 is comparatively ugly, has an outdated core in many parts and does not deal with Unicode on Windows. XEmacs-21.5 is not in workable state. And it is no secret that I don't use those myself, anyway. Since I can't offer qualified support for those, I can't really make compelling offers including them. And I don't actually want to. I want to work with Emacs and recommend Emacs. Let's not make things worse for our users than necessary if we can help it. If I feel already compelled to switch this off for myself to be able to work with Emacs sensibly, it does not make sense throwing this setting at the general world. Sorry for ranting and feeling strongly about this, and probably appearing way too impatient. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum