Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!pollux!dalsqnt!usl!usl-pc!jpdres10
From: jpdres10@usl-pc.usl.edu (Green Eric Lee)
Newsgroups: comp.editors
Subject: Re: Editor extensibility
Message-ID: <97@usl-pc.usl.edu>
Date: 14 Nov 88 18:57:55 GMT
References: <4052@enea.se>
Reply-To: elg@killer.UUCP (Eric Green)
Organization: Univ. of Southwestern La., Lafayette
Lines: 51

In article <4052@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>Kyle Jones (kjones@talos.UUCP) writes:
>>No version of Unipress Emacs that I have used has a built-in notion of
>>what consitutues a word.  It does have a default syntax table which
>>specifies word constituent characters, but these can easily be changed
>>on the fly, or via a per-user initialization file.
>
>you screw and fix with the syntax tables. (forward-word) will
>still leave me at the end of next word, instead of the beginning
>where I want to go. 

I haven't used Unipress in years (GNU Emacs spoken here), but I do
remember that it has MockLisp extensibility. Simply define a command
"next-word" which does (    (forward-word) (back-word)  ) and bind it
to a keystroke somewhere. 

> Also, I don't want a move-by-word command pass line borders. 

What's a line border? Sounds like YOU are making artificial
assumptions here! Why should a \n be any different from any other
white-space character in a file (as defined by the syntax-table)?  In
GNU Emacs, I know you COULD write a Lisp function which goes snooping
character-by-character and won't pass the end-of-line... but I'd hate
to see how slow that'd be (even byte-compiled Lisp is slower than
compiled "C").

>  If Emacs hadn't had this built-in presumption of what I want,
>it would have been smaller and faster.

Emacs is large. VERY large. But I have been quite impressed by the
speed of GNU Emacs... under heavy load, it's actually FASTER than
MicroEmacs (which is 1/10th the size). I recall that Unipress Emacs
was no slouch either... only irritating thing about Unipress is that
Gosling went hog-wild on his screen redisplay algorithm, meaning that
it was a big loss if you had an unoptimized termcap entry that didn't
detail, EXACTLY, the cost of each operation (note that most termcap
entries are optimized for low line speeds, not for direct-connect 9600
baud, too).

Considering that word-forward/word-back etc. are VERY small "C" loops,
I really fail to see how they can be the cause of the largeness. Much
more likely is "featuritis", and, especially, the command language
interpreter. The "Jove" editor implements most of the features of most
Emacs variations, including shell windows etc., but has no command
interpreter. It is only 120K or so on a 3b2... still larger than "vi",
but not really THAT bad considering that it does most of what Unipress
or GNU Emacs will do.

--
Eric Lee Green                            P.O. Box 92191, Lafayette, LA 70509
     {ames,mit-eddie,osu-cis,...}!killer!elg, killer!usl!elg, etc.