Re: [tlug] Chocolates for Stephen

["SL Baur" <steve@example.com>]

On 4/28/08, Curt Sampson <cjs@example.com> wrote:
> Here's an interesting article:
>
>   http://steve-yegge.blogspot.com/2008/04/xemacs-is-dead-long-live-xemacs.html

Well, at least his subtitle is accurate - "Random whining and stuff."

>  Let anybody get the wrong idea, I'm not finding the proposed
>  euthanization of XEmacs so interesting, though I'd be interested in
>  hearing thoughts on it, and it's certainly a good flame war seed for a
>  slow day.

I'll concentrate on that part, since I don't particularly care for any IDEs
I've seen besides InfoDock/XEmacs/Emacs.

I'll start right off and write that I do not consider JWZ a hero, nor
do I consider
RMS one either in nearly every respect[1].

XEmacs stability was a problem in various releases, most notably 19.14, where
it was both significantly slower than 19.13 (and the FSFmacs of that time).

Following a release path from the mid 1990s, 19.15, 20.3, 20.4, 21.1 featured
an XEmacs becoming smaller, faster and stabler.  20.0 through 20.2 were
clearly labeled "beta" quality (20.0 should not have been released, but I was
stupid at the time), 20.2 though not up to later XEmacs' standards was clearly
better than 19.14.  Of the platforms listed that the author tried,
only Linux was
truly supported by me and for the others, Microsoft Windows NT was a brand
new port in the time frame listed.  I'll presume that he's lying about running
XEmacs on Microsoft Windows XP in 2001 and earlier.

I had huge problems keeping XEmacs up for long periods of time in the period
after 19.14, mostly due to image rendering bugs (which were stack smashing),
but after a brief disastrous experiment with ImageMagick, we managed to get
image rendering under control by 20.2.  Before then, I was keeping XEmacs
running for weeks at a time - it's difficult to keep it running for
too long when one
is expected to be running the latest and greatest code and there were a lot of
rapid changes over that time period.

I'll just point out that on my desktop at work, I have several XEmacs 21.1 on
Solaris processes started last year that are running just fine thank you and a
bunch of 21.4 on Linux processes running just about that long.

In a somewhat extended evaluation of Microsoft Windows XP/SP2 last year,
I couldn't keep the system running more than a week at a time (if that), so I
fail to see how any XEmacs (in)stability could be properly evaluated there.

He is correct in that FSFmacs has been steadily catching up in features.  We
*should not* be held to blame for interfaces that we invented that
Stallman chose
to implement differently.

The crux of the matter is that it really *is* different getting
patches into XEmacs.
We have a lot more taste in UI matters and we're a lot more open to change when
we are wrong.  I'll name two examples that Stallman rejected out-of-hand when
I tried to fix them over twenty years ago - Emacs is case sensitive
except for one
exception.

When key lookup is performed and the lookup fails, the case is smashed and the
opposite case is tried.  Now try running M-x global-set-key on a prefix map
that has no keys bound to <prefix> + key or <prefix> + SHIFT key.  YOU CAN'T
DO IT.

I'm not going to bother going into the corner cases why FSFmacs will sometimes
signal beginning-of-buffer when you attempt to scroll past the end of
the buffer,
maybe that's fixed now, as `next-line-add-newlines' fixed longstanding
Stallman braindamage - motion commands should *never* cause a textual
change.

I'd love to write more, but this isn't an XEmacs buffer and I'm feeling awfully
irritated right now.

P.S.
No chocolates for this Steve.  I'm lactose intolerant.

-sb

[1] Stallman got exactly one thing correct in his life - he designed a perfect
architecture for Emacs and one that Microsoft has capitalized beyond anyone's
wildest dreams.