From xemacs-m  Sun Dec  8 22:51:12 1996
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id WAA17508 for <xemacs-beta@xemacs.org>; Sun, 8 Dec 1996 22:51:11 -0600 (CST)
Received: (qmail 21042 invoked by uid 52477); 9 Dec 1996 04:51:08 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@xemacs.org>
Subject: Re: The future of XEmacs
References: <m2afrol569.fsf@altair.xemacs.org>
Mime-Version: 1.0 (generated by tm-edit 7.84)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 08 Dec 1996 23:51:08 -0500
In-Reply-To: Steven L Baur's message of 08 Dec 1996 20:20:30 -0800
Message-ID: <yviaenh0uxqb.fsf@atreides.mindspring.com>
Lines: 62
X-Mailer: Red Gnus v0.72/XEmacs 19.15

In article <m2afrol569.fsf@altair.xemacs.org>,
Steven L Baur <steve@miranova.com> writes:
> The Pros:
[ Snipped.  All of these are pros for the developer, not the user. :) ]

> The Cons:
[ Snipped ]

You missed one big con.  Lots of sites will refuse to upgrade to 20.x
until the series is well-advanced.  Educational instutions are
particularly bad in this respect.  Also, lots of users at such
institutions do not have the ability/resources to install their own
copy of XEmacs.  So, the last release of 19.x should fix all known
bugs.

In particular, the redisplay bug (where XEmacs hangs at the oddest
places until you provide any form of input) is particularly annoying
and is not the type of thing that should be left hanging in the final
19.x release.  It bites me literally dozens of times a day...I've
gotten into the habit of hitting C-l all the time.

> All in all, I'm leaning very heavily towards ditching 19.15, so if
> there are any objections, speak now or flame me in comp.emacs.xemacs
> for the next 3 years ;-).

Please don't do this.

> There *will* be a release of 19.15-b3 even if it's the final release
> of XEmacs v19.

I vote for this.

Also, I thought 19.15 was to be a bug-fix/speedups only release?  I'm
pretty certain that this is the perception on c.e.xemacs, for instance.

While on the subject, what about speed?  Your benchmarks compare
versions from 19.14 and up.  The thing is, 19.14 and up are all
extremely slow on a large number of the platforms out there, when
compared to GNU Emacs.

Is it unacceptably slow?  I do not know.  It'd depend on the person
and the machine.  I do know that I simply could not use it in everyday
work (Linux 2.x on a P133 with 64Megs and a Seagate Hawk) until I
compiled it with all pentium-gcc optimisations turned on, using a
pre-release, buggy-as-hell, version of gcc.  It's fast enough now, but
I have to live with the fact that certain operations cause my XEmacs
to die (compiler flaws, not XEmacs bugs).  The point is that I
couldn't have used it w/o messing with the compiler (and trying out
all combinations of flags with several files).

Even now, I see strange slowdowns.  For instance, sometimes cursor
movement and general responsiveness gets extremely slow.  This seems
to be tied into having multiple frames open.  But, it doesn't happen
all the time.  Switching to another frame to work in will _sometimes_
cause the problems to go away.  Sometimes it goes away by itself after
a little while.  Redisplay bug?  Compiler bug?  Dunno.

I'm getting a PPro soon (yay!), so this should be less of a problem
for me.  But, I bet it's still a large problem for lots of people who
might use XEmacs otherwise.

-Sudish

