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

[Barak Zalstein]

> I'll start a download of xemacs tonight before turning in. 
Even before thinking about xemacs internal architecture, there are some 
noticeable
problems to the untrained eye:

1. Long download and install time. 
The natural download choice for me was the  precompiled binary 
(http://xemacs.org/Download/win32/setup.exe) and I'm not sure how latest and 
greatest it is (newer is not always better, but frequent releases make better 
impression). 
Even though there are lot of packages to be downloaded, extracted, and 
installed by the automatic installer, it just makes more sense to be able to 
download a large executable to local HD and then run it with faster response 
time.
2. GNU vendor "lock-in" . 
I don't have lots of customizations, but the automatic .emacs migration 
was a failure (it doesn't know about set-background-color function, running 
gnus results in nntp error). 
I think that it is reasonable to expect from a user to ditch the evaluation 
when missing a feature already accustomed to.
3. A "Superstition" aspect mentioned earlier.
If you want to bring new users, how can one handle the approach of
"I already have an editor/browser/MUA etc., why should I learn this one?" . 
Education and preaching will not help.

(replace editor and vendor with your favorite application examples).

As for the language wars, even though LISP is considered better in various 
fields for many years now (in my context: 
http://groups.google.com/groups?selm=ludemannCzw2Hy.B8y%40netcom.com&oe=utf-8&output=gplain),
 the tendency is to use building blocks that already exist (having years of 
implementation behind those building blocks,
the question of considering a new implementation architecture becomes almost 
irrelevant).

Barak.