🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.editors
Article #3370

Re: Editor extensibility

#3370
From: Erland Sommarskog
Date: Mon, 21 Nov 1988 21:48
54 lines
2777 bytes
Eric Green (elg@killer.UUCP) writes:
>I said:
>> 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! 

If I wrote an editor and made the word commands to never cross
line boundaries, I would be guilty of an artificial assumption.
However, I was only talking about my own personal taste. The point
was that it is no good to build in a concept that doesn't fit
every user. Better to offer simple primitives with which the 
user can implement the higher-level concepts as he want them.

>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").

That is what I have done. And it's not slower than anything else 
in this snail to an editor. Hell, I have to wait for echoing of
characters sometimes! And right I deleted a line. That took five
seconds. Loaded system? Yes, a lot of uucp around, but I work
with TPU on a loaded VMS system daily, an d while I'm in the editor
I don't even notice this.

>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).

I mostly run Emacs at 1200 and I see little use of Mr. Goslings algorithms.

>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 word functions are of course only an example. The command language
interpreter is probably slow, but it shouldn't. That is one of the
most important parts of a programmable editor.

And for built-in assumptions here's another of my pet peeves. (And
in this case Emacs and TPU are equally bad.) If I do an case-insentive
search I want the pairs ]} [{ \| to be equivalent just as Aa Bb etc.   
Simply because they are letters on my screen. (Mayne I should be too
hard on Emacs here. There may be a funtion that I've missed.) 
-- 
Erland Sommarskog
ENEA Data, Stockholm
sommar@enea.se
"Frequently, unexpected errors are entirely unpredictable" - Digital Equipment
Technical Details
Message-ID: <4100@enea.se>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!mcvax!enea!sommar

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.editors
Subject: Re: Editor extensibility
Message-ID: <4100@enea.se>
Date: 21 Nov 88 21:48:57 GMT
Organization: ENEA DATA AB, Sweden
Lines: 54