gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] RE: [OT] fixing emacs


From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] RE: [OT] fixing emacs
Date: Mon, 01 Sep 2003 14:37:14 +0900
User-agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.4 (Portable Code, linux)

>>>>> "Barak" == Barak Zalstein <address@hidden> writes:

    Barak> 1. Long download and install time.

    Barak> The natural download choice for me was the precompiled
    Barak> binary (http://xemacs.org/Download/win32/setup.exe) and I'm
    Barak> not sure how latest and greatest it is (newer is not always

It's current, about 3 months old.

    Barak> better, but frequent releases make better impression). Even
    Barak> though there are lot of packages to be downloaded,

The packages are also current.  Some of them are less than two weeks
old.

    Barak> extracted, and installed by the automatic installer, it
    Barak> just makes more sense to be able to download a large
    Barak> executable to local HD and then run it with faster response
    Barak> time.

We've discussed the issue of monolithic (InstallShield-style) installs
at some length, and what it came down to was that we wanted to support
classic free-software development styles well on Windows, not attract
the maximum number of Windows users.  The system we have allows much
more rapid turn-around on both packages and core updates, and we
distribute and support (== respond to bug reports, of course almost
all run on GNU Emacs) a much wider variety of packages than GNU Emacs
does.

    Barak> 2. GNU vendor "lock-in" . 

There's nothing we can do about GNU unwillingness to cooperate, which
goes back to the Lucid era.  All we can do is to synchronize ex post.

    Barak> I think that it is reasonable to expect from a user to
    Barak> ditch the evaluation when missing a feature already
    Barak> accustomed to.

For many users, I agree.  I think (of course!) that from many points
of view XEmacs is an improvement over GNU Emacs, but it is not (and
cannot be, for the reason given above) an "upgrade" from GNU Emacs.
Only those users who need specific features or just like trying new
things should switch.  (This is my personal opinion, not the official
position of the XEmacs project; there is no official position on this.)

    Barak> 3. A "Superstition" aspect mentioned earlier.

    Barak> If you want to bring new users, how can one handle the
    Barak> approach of "I already have an editor/browser/MUA etc., why
    Barak> should I learn this one?" . Education and preaching will
    Barak> not help.

We don't care.  If you already have reason to use an Emacs on Windows,
XEmacs probably will give you good "moral support", as the currently
most prolific developers are Windows-based.  If you're not already an
Emacs person, then we talk a lot, but it's not really our mission to
convince you to switch.  Whether you use GNU Emacs or XEmacs is
similarly not a religious issue for me.  GNU Emacs is a great program,
source of many of our features and implementations, but there are a
few areas where XEmacs is obviously ahead of GNU Emacs (and vice versa).

    Barak> As for the language wars,

It's not a language issue.  It's all about the architecture, ie, programs
capable of introspection and automatic construction of subprograms.

LISP is simply the unique language family designed so that a
syntactically correct program is constructed uniformly using the data
structure the language is optimized for handling, making this
relatively straightforward.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]