Xref: utzoo comp.misc:5699 comp.editors:608
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!husc6!bloom-beacon!tut.cis.ohio-state.edu!osu-cis!att!ihlpb!gregg
From: gregg@ihlpb.ATT.COM (Wonderly)
Newsgroups: comp.misc,comp.editors
Subject: Re: UNIX needs a real text editor
Message-ID: <10099@ihlpb.ATT.COM>
Date: 2 Apr 89 19:06:13 GMT
References: <248@usl-pc.usl.edu>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 62

From article <248@usl-pc.usl.edu>, by jpdres10@usl-pc.usl.edu (Green Eric Lee):

...stuff about EMACS speed deleted

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

The point I was trying to make is that LISP is not a common language base for
most people.  A more procedural language such as TPU looks and feels more
comfortable.  E.g. something like the following is infinitely easier for me to
read than lisp.

PROCEDURE split_window

	LOCAL
		newwin1,
		newwin2,
		wintop,
		slop,
		winlen;

	winlen := GET_INFO (CURRENT_WINDOW, "VISIBLE_LENGTH");

	IF (winlen < 3) THEN
		MESSAGE ("Current window too small to split");
		RETURN;
	ENDIF;

	wintop := GET_INFO (CURRENT_WINDOW, "VISIBLE_TOP");
	slop := winlen - ((winlen / 2) * 2);

	! subtract 1 from length for status line.

	newwin1 := CREATE_WINDOW (wintop, (winlen / 2) - 1, ...);
	newwin2 := CREATE_WINDOW (wintop + (winlen / 2), (winlen / 2) - 1 + slop, ...);

	! Map both windows to the current buffer.

	MAP (newwin1, CURRENT_BUFFER);
	MAP (newwin2, CURRENT_BUFFER);

	! Delete the old window.

	DELETE (CURRENT_WINDOW);
	POSITION (newwin1);
ENDPROCEDURE;

And the compilation of this, or any other interpretive language, can compact a lot
of the expressions because we know how to do these things, whereas I don't know
of anybody (I have not looked) applying any optimization or other speed ups to lisp
based interpreters.  Given the difference in speed (I know how DEC did this, the
interpreter is a giant VAX case instruction) I would say that the EMACS I used on
the same VAX as TPU was not very efficient.

-- 
Gregg Wonderly                             DOMAIN: gregg@ihlpb.att.com
AT&T Bell Laboratories                     UUCP:   att!ihlpb!gregg