Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!purdue!mentor.cc.purdue.edu!j.cc.purdue.edu!nwd
From: nwd@j.cc.purdue.edu (Daniel Lawrence)
Newsgroups: comp.emacs
Subject: Re: Programmable Editors
Summary: uEMACS programming
Keywords: uEMACS macroes
Message-ID: <9689@j.cc.purdue.edu>
Date: 29 Jun 89 14:18:36 GMT
References: <780@crdgw1.crd.ge.com> <251@tigger.planet.bt.co.uk> <25295@shemp.CS.UCLA.EDU>
Reply-To: nwd@j.cc.purdue.edu (Daniel Lawrence)
Organization: Purdue University
Lines: 110

In article <25295@shemp.CS.UCLA.EDU> srt@cs.ucla.edu (Scott Turner) writes:
>
>  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.
>
	But you are missing a point here.  MANY users are not tied to a
specific machine.  Editing macroes that can be used portably between a
one user machine, and a mainframe allow the user to design their own
editing environment which is independant of the particular machine they
are currently on.

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

	I have seen simply too many requests for too many different
editing environments to resonable compile them all into the editor at
one time.  Arguable, on a micro, a user could use conditional
compilation to configure an editor... but again the question of
portability across platforms comes up.

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

	Specifically for MicroEMACS... there is a EBIND.H header file
containing the initial key bindings for the key definitions.  Also
ESTRUCT.H allows you to keep or discard certain sets of features. 
Changes to this are rather easy and would allow a user to configure
their own editor.

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

	Good programming probably negates this argument.  The amount of
time needed to read in apx 60 lines of key rebindings at startup time in
MicroEMACS is apx .1 of a second (on a 286 PS/2 model 60).  Even on a 4
hz XT I doubt this is more than .5 seconds.

>Second, such an editor will as small and efficient as possible, since
>unused portions of the editor won't be included in the executable.
>

	Key bindings occur in a relativily small static binding table.
(MicroEMACS defaults [check the constants in estruct.h] to 300 bindings,
occupying 8 * 300 = 2400 bytes on the PC.  This is negligible from both
a size and efficiency standpoint.  Your point is valid for the various
environments being macro loaded however.

>  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
>
	From my understanding of MSDOS, a dump facility would be
difficult at best.  The executing source code no longer retains the
information on where "fixups" need to occur in the executable image in
order to load it into different places in RAM.  While the original EXE
file could be scanned for the code fixups, such an image would also need
some way of generating the proper data fixups for the currently declared
variables, and heap space.  Sounds like a real mess. (And, needless to
say, VERY machine dependent).

	Alternativly, when I needed to produce a mail reader for a large
project at Purdue, where I work, I wrote a 1400+ line macro to prototype
it.  Then, translating the macro to C code, I quite easily linked it in
to EMACS, adding a single entry to the tables in EFUNC.H and EBIND.H to
make the code accessable.

	Many times I have put together a "CUSTOM" uEMACS with special
commands for special purposes.  I am thinking that if the interest is
expressed here, I could work on a new chapter for the uEMACS manual
which would explain how to do this to others  (It's really quite simple.)

> 
>    Scott R. Turner
>    UCLA Computer Science     "I just want OUTTA here"

			Daniel Lawrence  voice: (317) 742-5153
					  arpa:	dan@midas.mgmt.purdue.edu
				The Programmer's Room 
				Fido: 1:201/10 - (317) 742-5533