Re: xassert in dispextern.h

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> Miles Bader <address@hidden> 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