Xref: utzoo comp.misc:5696 comp.editors:606
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!killer!usl!usl-pc!jpdres10
From: jpdres10@usl-pc.usl.edu (Green Eric Lee)
Newsgroups: comp.misc,comp.editors
Subject: Re: UNIX needs a real text editor
Message-ID: <248@usl-pc.usl.edu>
Date: 31 Mar 89 16:24:31 GMT
References: <4392@enea.se>
Reply-To: jpdres10@usl-pc.UUCP (Green Eric Lee)
Organization: Univ. of Southwestern La., Lafayette
Lines: 56

In article <4392@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>Gregg Wonderly (gregg@ihlpb.ATT.COM) writes:
> >My opinion is that as long as xMACS editors continue to use a language
> >such as lisp for programability there will continue to be resistance.
> >Every version I have tried to implement vi's % operator in has failed
> >miserably in speed.
>Hear, hear! Just couldn't agree more. Emacs may have cool 
>functionality, but I doubt to call it a serious editor,  
>after all the times I just waited for it to echo a typed 
>character. Now, TPU, that is a serious editor. 
>Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se

You wait for Emacs to echo a typed character? The only time I've
waited for GNU Emacs to echo a typed character is when the machine is
seriously overloaded (e.g. a dozen Prolog and Lisp hackers merrily
doing their thing). I have noticed that GNU Emac's redisplay algorithm
is about as efficient as an "intelligent" algorithm can get -- its
response time is even faster than the MicroEmacs editors that I've
seen (which certainly don't have the excuse of being "big" to account
for their speed). Even under load.

Of course, I can only vouch for GNU Emacs under Unix (BSD4.x Pyramids
here, high end 3b2 running Sys V.3 elsewhere). I suspect it would be
far less efficient under VMS, because it was originally designed to
run under Unix and was sort of hacked, kludged, and shoe-horned in
order to run under VMS.

As for Emacs Lisp: Lisp is a naturally interpretive language of far
greater power than the usual limited Teco-style extension language.
The speed problems come from the fact that it HAS to be interpreted,
even if you tokenize it into byte-codes -- Emacs runs on dozens of
different machines, with dozens of word organizations and machine
languages. If you have an extension language for an editor which was
designed for one single machine, and will only run on that one single
machine, naturally you can make it run more efficiently than a
generalized solution -- at least, on that one single machine. Compiled
Lisp has come close to matching Fortran for speed (see Multics MacLisp
for an old example). But compilation simply isn't feasible when you're
trying for a generalized solution that runs on dozens of different
machines.

I suggest that if your Emacs staggers and stutters, that you suggest
to your management that your company/university/etc. aquire adequate
resources for the pursuit of your mission. It's not Emac's fault that
you are trying to run it on seriously overloaded equipment, or under
an operating system for which it was not designed. If your equipment
is too overloaded to run Emacs, it's probably too overloaded for
efficient program development and research, too. I have struggled on
without adequate equipment when necessary, but it generally takes two
to four times longer to develop a program than when you have adequate
resources available.

--
|    // Eric Lee Green              P.O. Box 92191, Lafayette, LA 70509     |
|   //    {uunet!dalsqnt,killer}!usl!elg     (318)989-9849                  |
| \X/              >> In Hell you need 4Mb to Multitask <<                  |