🚀 go-pugleaf

>I have also worked with MicroEmacs, and it's macro language is a hack.
>Syntacticly it's very messy.  I have also worked with Bill Frolik on
>an editor for the HP-3000 that had a macro language.  The only
>acceptable solution (IMHO) is to *start* with a programming language
>and add editor primitives, rather than start with an editor and add a
>programming language to it.

This is true in almost any environment.  IBM's VM editor, XEDIT, follows the
same rule.  It provides a rich set of primitives, and allows them to be
invoked from the equivalent of the shell, REXX.  REXX is a very flexible
language, and is used for many purposes in VM.  The obvious benefit of using
it for writing XEDIT functions (XEDIT calls them "macros", although strictly
speaking they aren't) is that there isn't any new programming language to
learn.  The odds are *very* high that anyone interested in writing an XEDIT
function has already written some REXX programs.  I presume this is why EMACS
uses LISP:  The odds are very high, in the AI community, that anyone
interested in writing an EMACS function has already written some LISP code.
The fact that, except to extend EMACSen, few of us outside that community
write LISP on a regular basis seems to have been ignored, if it has been
noticed at all.  I find it quite a tribute to EMACS' utility that it survives
anywhere outside the AI world, despite the handicap of an otherwise rarely
used extension language.

Ross Patterson
Rutgers University
Center for Computer and Information Services