Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ucla-cs!srt
From: srt@maui.cs.ucla.edu (Scott Turner)
Newsgroups: comp.emacs
Subject: Re: Programmable Editors
Message-ID: <25295@shemp.CS.UCLA.EDU>
Date: 28 Jun 89 17:10:16 GMT
References: <780@crdgw1.crd.ge.com> <251@tigger.planet.bt.co.uk>
Sender: news@CS.UCLA.EDU
Reply-To: srt@cs.ucla.edu (Scott Turner)
Organization: UCLA Computer Science Department
Lines: 54


  The recent discussion of whether or not mEmacs is programmable has
triggered me to think a bit about whether or not one wants, on a
micro, a programmable editor at all.

  There are two major advantages to a programmable editor.  First, it
allows multiple users to extend their editor in whatever ways they
desire, independent of other users.  This avoids the problem of every
user on a multi-user machine having their own editor.  Second, it
allows a single user to customize his editor to the current
application.  That is, he can load his C-Mode macros while hacking C
code, the TeX macros while writing text in TeX and so on.

  The first reason isn't important in many micros situations.  Many
micros are primarily one-user machines.  In this case, the user is
free to permanently set up his editor any way he'd like, obliviating 
the need for a programmable editor.

  The second reason can be important on a single-user machine,
although primarily if the user has a wide-range of editing tasks and
if the editor programs for those tasks are large.  In a situation
where there are only a few tasks and the editor programs are
reasonable, they can be built in to the code.

  In light of this, what is needed more than a programmable editor is
one that can be programmed at build-time.  In some sense, any editor
is build-time programmable - you can always hack the source code.
(And I do :-)  But it would be nicer to have simple facilities for
some of the common editor programming tasks.   A "keydefs.h" file
which could be modified to change the key definitions, for instance.
A facility for including/excluding code based on the tasks to which
the editor will be applied.  And so on.

  There are two advantages to this.  First, such an editor will have a
quicker start-up time, since it will not have to read initialization
files.  And that's important under an OS like MS-DOS where there is no
job control and an editor may be started many times in a session.
Second, such an editor will as small and efficient as possible, since
unused portions of the editor won't be included in the executable.

  I've been assuming that the build-time programming occurs at the
source code level, but another possibility is a macro language and a
dump facility, such as GNU Emacs.  The disadvantage of this is speed.
The interpreted macro language will never be as fast as native source
code.  (Incidentally, does Freemacs have a dump feature?)

						-- Scott Turner



 
    Scott R. Turner
    UCLA Computer Science     "I just want OUTTA here"
    Domain: srt@cs.ucla.edu