I've been giving some thought to writing a text editor in Common
Lisp. I'm aware of Hemlock/PHemlock although I have not studied the
sources. I'm at the early stages of thinking about this and I don't
really know how big a job it is to do something on the order of Emacs
in Common Lisp. Not that I would start out with all that
functionality, but it is probably best to have a foundation that will
support it.
So I would like to start off with a simple question. What is the best
underlying data structure to hold the text to be manipulated? I've
been thinking an array of strings (one string per line) would be the
way to go. Or perhaps an array of arrays. I'm not presently worried
about trying to deal with binary files, but you never know.
Text editing is not exactly a new art. I've just never done it
before. Are there any online sources that would be useful to me?
What advice do you have?
A blue sky goal would be the functionality of Emacs. I also wish to
keep display/input logic as seperate as possible from the actual
buffer handling and text editing functions. That way, I can keep the
back end ANSI Common Lisp and take advantage of implementation
features for the UI and not have to rewrite the back end stuff if I
port to a different CL implementation.
There are some other things I'm not sure about. Apart from the raw
text, there is usually other state information:
* text insertion point
* any marks
* syntax highlighting (is this strictly a display issue?)
* paren matching
* character encoding (ASCII, Unicode, etc)
I've also considered writing a s-exp editor, but I have no idea how to
deal with issues such as comments and case preservation. Also there
are things like REPL and debugger functionality (any TTY type stuff
really) that I would like to be able to handle. I would also like to
be able to use this editor as the core for a Lisp IDE. Emacs seems to
be a good model. I haven't studied Emacs sources either, nor do I
know ELisp.
If I move on this, I will initially target OpenMCL and the Carbon API
for the UI on OSX. Keeping the display logic separate from underlying
buffer management and text editing functions is more of a hedge in
case I feel the need to go with another Lisp (like SBCL on Linux or
whatever). I also want to be able to do the text handling stuff
before I worry too much about the UI.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> I've been giving some thought to writing a text editor in Common
> Lisp.
Don't know how much you want to do yourself. But, if you are interested
is using a very nice DLL/library (cross platform) you may want to take
a look at Scintilla (www.scintilla.org). I've used it before for little
embedded script editors and it is a beauty to work with.
Jeff
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
David Steuber <·····@david-steuber.com> writes:
> I've been giving some thought to writing a text editor in Common
> Lisp. I'm aware of Hemlock/PHemlock although I have not studied the
> sources.
I'd work on Hemlock, it's not bad.
> So I would like to start off with a simple question. What is the best
> underlying data structure to hold the text to be manipulated?
http://dept-info.labri.u-bordeaux.fr/~strandh/Projects/Lseq/
The array of line is nice for ed(1), but I don't like it for
emacs-like editors. I feel that while buffer character indexing is
better (with an underlying optimization).
> Are there any online sources that would be useful to me?
ftp://ftp.gnu.org/gnu/emacs/emacs-21.3.tar.gz
cvs -d ··················@common-lisp.net:/project/phemlock/cvsroot \
co -P hemlock
Really? Don't you know how to use google or the search box in cliki.net?
> I've also considered writing a s-exp editor, but I have no idea how to
> deal with issues such as comments and case preservation.
http://www.grammatech.com/products/sg/overview.html
http://portal.acm.org/citation.cfm?id=808247
A s-exp editor is actually a "source" editor. Ok, it actually edits a
syntax tree, but it's a source sexp. It's not feed to the REPL, if
only because it may well not be complete!
The normal sexp syntax is something like:
sexp ::= atom | '(' sexp-list ')' ;
sexp-list ::= | sexp sexp-list ;
if you want to keep the comments, you have to change the grammar:
sexp-list ::= | sexp comment sexp-list ;
comment ::= | '#|' sharp-comment-text '|#'
| ';' semicolon-comment-text ;
In any case, the sexp editor would probably unparse (to text) the
source to send it to the lisp system.
Note a difficulty with such an editor: in Common-Lisp you can change
the syntax with reader macros.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon wrote:
> Note a difficulty with such an editor: in Common-Lisp you can change
> the syntax with reader macros.
I would imagine that an editor written in Lisp could easily work around
this. Just use read and typecase to colorize.
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
"Jeff" <···@nospam.insightbb.com> writes:
> Pascal Bourguignon wrote:
>
> > Note a difficulty with such an editor: in Common-Lisp you can change
> > the syntax with reader macros.
>
> I would imagine that an editor written in Lisp could easily work around
> this. Just use read and typecase to colorize.
How do you colorize this:
(some-mangling-of-the-read-table)
#[
main(v,c)char**c;{for(v[c++]="Hello, world!n)";
(!!c)[*c]&&(v--||--c&&execlp(*c,*c,c[!!c]+!!c,!c));
**c=!c)write(!!*c,*c,!!**c);}
]
(some-other-mangling-of-the-read-table)
#[
C FIND QUADRATIC ROOTS.
5 READ (5,1,END=2) A,B,C
1 FORMAT (3F10.0)
IF (A .NE. 0) GO TO 100
IF (B .NE. 0) GO TO 100
IF (C .NE. 0) GO TO 100
GO TO 2
100 DELTA = B**2-4*A*C
IF (DELTA .LT. 0) GO TO 10
X1=(-B-SQRT(DELTA))/(2*A)
X2=(-B+SQRT(DELTA))/(2*A)
PRINT 4,A,B,C,X1,X2
4 FORMAT ('A=',F10.0,' B=',F10.0,' C=',F10.0,' X1=',E15.6,
- ' X2=',E15.6)
GO TO 5
10 PRINT 14,A,B,C
14 FORMAT ('A=',F10.0,' B=',F10.0,' C=',F10.0,
- ' PAS DE SOLUTION REELLE')
GO TO 5
2 STOP 1
END
]
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon wrote:
> "Jeff" <···@nospam.insightbb.com> writes:
>
> > Pascal Bourguignon wrote:
> >
> > > Note a difficulty with such an editor: in Common-Lisp you can
> > > change the syntax with reader macros.
> >
> > I would imagine that an editor written in Lisp could easily work
> > around this. Just use read and typecase to colorize.
>
> How do you colorize this:
[extreme case snipped]
LOL, rather extreme isn't it? I think we could agree that if he can get
98% of all cases very easily, and your example being in the last 2%,
the world is a very pleasant place ;)
As for my own answer to that question, I would still follow my original
idea of just reading the text. If it wasn't understood, just leave it
as plain-text. In your example, that would most likely constitute
everything from #[ to ]:
(defun colorize (stream)
(typecase (read stream nil)
(string :green)
(number :red)
(keyword :blue)
(otherwise :black)))
I'm sure you mean well by trying to point out difficulties, but I don't
see the point in trying to discourage the OP. Your example is very
extreme, and quite possibly the OP wouldn't be coding anything like
what you propose -- in which case it doesn't matter if his editor
handles that particular case or not.
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
Pascal Bourguignon <····@mouse-potato.com> writes:
> How do you colorize this:
>
>
> (some-mangling-of-the-read-table)
> #[
> main(v,c)char**c;{for(v[c++]="Hello, world!n)";
> (!!c)[*c]&&(v--||--c&&execlp(*c,*c,c[!!c]+!!c,!c));
> **c=!c)write(!!*c,*c,!!**c);}
> ]
> (some-other-mangling-of-the-read-table)
> #[
> C FIND QUADRATIC ROOTS.
> 5 READ (5,1,END=2) A,B,C
> 1 FORMAT (3F10.0)
> IF (A .NE. 0) GO TO 100
> IF (B .NE. 0) GO TO 100
> IF (C .NE. 0) GO TO 100
> GO TO 2
> 100 DELTA = B**2-4*A*C
> IF (DELTA .LT. 0) GO TO 10
> X1=(-B-SQRT(DELTA))/(2*A)
> X2=(-B+SQRT(DELTA))/(2*A)
> PRINT 4,A,B,C,X1,X2
> 4 FORMAT ('A=',F10.0,' B=',F10.0,' C=',F10.0,' X1=',E15.6,
> - ' X2=',E15.6)
> GO TO 5
> 10 PRINT 14,A,B,C
> 14 FORMAT ('A=',F10.0,' B=',F10.0,' C=',F10.0,
> - ' PAS DE SOLUTION REELLE')
> GO TO 5
> 2 STOP 1
> END
> ]
I would recommend using the same colour for background
and foreground.
--
Gareth McCaughan
.sig under construc
Jeff wrote:
> Pascal Bourguignon wrote:
>
>
>>Note a difficulty with such an editor: in Common-Lisp you can change
>>the syntax with reader macros.
>
>
> I would imagine that an editor written in Lisp could easily work around
> this. Just use read and typecase to colorize.
Probably it's a little more complicated than that. For example, how do
you read if the text includes references to packages that are not
defined in the editor? What if the text being edited uses fancy syntax
macros that depend on functions and data structures that are not defined
in the editor? Does the editor have to compile and load every program it
edits before it can edit anything?
Pascal Bourguignon <····@mouse-potato.com> writes:
> > Are there any online sources that would be useful to me?
>
> ftp://ftp.gnu.org/gnu/emacs/emacs-21.3.tar.gz
> cvs -d ··················@common-lisp.net:/project/phemlock/cvsroot \
> co -P hemlock
>
> Really? Don't you know how to use google or the search box in cliki.net?
I have GNU Emacs and Portable Hemlock from CVS already. That wasn't
what I ment by sources. I was asking about texts that discuss the
theory of designing and implementing a text editor.
Thanks for your other links.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Text editing is not exactly a new art. I've just never done it
> before. Are there any online sources that would be useful to me?
> What advice do you have?
Emacs Implementations and Literature
http://www.finseth.com/~fin/emacs.html
http://www.finseth.com/craft/
--
Johan Bockg�rd
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Writing a Text Editor in Lisp
Date:
Message-ID: <87isaklpvg.fsf@qrnik.zagroda>
David Steuber <·····@david-steuber.com> writes:
> So I would like to start off with a simple question. What is the best
> underlying data structure to hold the text to be manipulated?
A structure which will make possible to be replaced with a different
structure with few changes in the program. I think anything reasonable
will do, as long as it's easy to experiment with other choices in the
future, when its shortcomings will be known.
More important is the question how the interface of a text buffer
should look like. This is what will be hard to change, it will be used
in lots of places, so it must be carefully designed; e.g. whether
to use implicit current point or explicit markers to specify where
actions are to be performed; whether to treat end-of-line as a character
like others or to treat the buffer as consisting of lines which consist
of characters; how to manipulate metainformation, i.e. everything apart
from the actual text.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On 11 Sep 2004 11:29:20 -0400, David Steuber <·····@david-steuber.com>
wrote:
> What advice do you have?
The most common type of data structure used in a editor is
what is known as a gap editor.
In essence a gap is opened around the cursor position so it takes
less operations to move memory around the text.
A quick search of Gap editor implementation brought up this:
http://ned.rubyforge.org/
It seems to have a lot of links to everything about editors.
Have fun!
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Am 11 Sep 2004 11:29:20 -0400 schrieb David Steuber
<·····@david-steuber.com>:
> I've been giving some thought to writing a text editor in Common
> Lisp. I'm aware of Hemlock/PHemlock although I have not studied the
> sources. I'm at the early stages of thinking about this and I don't
> really know how big a job it is to do something on the order of Emacs
> in Common Lisp.
It's really BIG. And it'll take you A LOT of time. So if you to get ready
someday I think you should better participate in an existing project.
The big problem AFAICS is that every design decision has some huge
influence on the rest. Eg. a line based internal representations may ease
implementing inline images, but it's quite a bunch of overhead, whereas
buffer-based storing may create really long insertion times for big files.
Also what features should my gap-buffers have? Where to store font
information? etc.
But nevertheless, here're some resources I found useful:
* see the hemlock implementation (I think it's available with McClim),
eg. take a look at the flexi-buffer implementation
* http://www.finseth.com/craft/
"The Craft of Text Editing"
* Hm, I think there was some nice stuff on the cliki.tunes.org but
cannot find it, ATM.
"Thomas Schilling" <······@yahoo.de> writes:
> * see the hemlock implementation (I think it's available with McClim),
> eg. take a look at the flexi-buffer implementation
The editor pane that comes with McCLIM is called Goatee. Portable
Hemlock, besides the default CLX-based GUI, also has an experimental
one (currently broken, as far as I know) based on McCLIM.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
David Steuber <·····@david-steuber.com> writes:
> So I would like to start off with a simple question. What is the best
> underlying data structure to hold the text to be manipulated? I've
> been thinking an array of strings (one string per line) would be the
> way to go. Or perhaps an array of arrays. I'm not presently worried
> about trying to deal with binary files, but you never know.
It is hard to say which is the "best" data structure without knowing
more about performance requirements and such.
GNU Emacs uses (or at least it did at some point, perhaps that has
changed) a gap buffer to hold the entire text of the buffer. It is a
fairly simple implementation that is efficient when a sequence of
insert and delete operations are close to each other in the buffer.
If they are far apart, the entire text may have to be moved at each
operation. This data structure makes it hard to determine information
about lines, such as which line point is on and how many lines there
are in the buffer.
Multics Emacs used a doubly linked list of strings, on string per
line. Each insert and delete operation moved every character to the
right of point on the same line. This structure works fine if lines
are short, but can be quite slow when lines are long. Though today
your average PC is about 1000 times as fast as the Multics machine at
the time, so this is probably not a huge problem. Searching for a
string with newlines in it gets more complicated than in the case of a
single gap buffer.
Hemlock uses a doubly linked list of lines. Each line except the
current (open) one is a string. The current one is implemented as a
gap buffer. A bad case for this structure would be alternating
editing operations on different lines, which would require conversions
between a string and a gap buffer at each operation. This problem
could be fixed by allowing several lines to be open and close them in
an LRU order.
It is probably not a good idea to expose the doubly linked list of
lines as part of the API. In Hemlock, given a line, the API allows
you to find the previous or the next line, which essentially
*requires* a doubly linked list. It then gets very hard to change the
data structure later if desired.
There is also the issue of "undo". If you store the text in a
tree-like data structure, each editing operation would cost O(log n)
which is not too bad on today's machines. You then get undo for free,
since you can easily share most of the tree between all versions. In
the structures above, you would have to save undo information for each
operation.
> Text editing is not exactly a new art. I've just never done it
> before. Are there any online sources that would be useful to me?
> What advice do you have?
The code of Portable Hemlock is mostly pretty easy to read, even
though some of it is pretty old looking with lots of structures
instead of classes and some optimizations that were probably necessary
at the time but that know mostly makes maintenance harder.
> A blue sky goal would be the functionality of Emacs. I also wish to
> keep display/input logic as seperate as possible from the actual
> buffer handling and text editing functions. That way, I can keep the
> back end ANSI Common Lisp and take advantage of implementation
> features for the UI and not have to rewrite the back end stuff if I
> port to a different CL implementation.
>
> There are some other things I'm not sure about. Apart from the raw
> text, there is usually other state information:
>
> * text insertion point
> * any marks
If you have a gap buffer, you can attach marks to physical locations
in the buffer so that marks do not need to be updated at each
operation. In the case of a string per line, you need to update all
marks on that line at each operation.
> * syntax highlighting (is this strictly a display issue?)
Pretty hard stuff. Essentially, you need to scan the entire buffer
from the beginning by a parser that knows the language you are
editing. GNU Emacs cheats by only backing up as far as a line with no
blanks in the first column.
You could also use a parser with explicit state (including the stack)
and attach that state every so often to a mark. If you have explicit
lines, you can attach this information to a line.
Of course, if you are editing Common Lisp, all bets are off if someone
changes the read tables. The best you could do would be to write your
own version of read with explicit state information, and only
highlight when you are in one of the predefined CL read functions.
> * paren matching
Essentially the same issue as syntax highlighting.
> * character encoding (ASCII, Unicode, etc)
If you use Unicode, you need 21 bits per character. It might then be
worthwhile to allow for a more compact representation of chunks of
text needing only 8 bits per character. You could use something like
UTF-8, but I suspect it would be a nightmare to implement even the
basic editing operations. If you have lines, each line could
potentially have a different representation.
> I've also considered writing a s-exp editor, but I have no idea how to
> deal with issues such as comments and case preservation. Also there
> are things like REPL and debugger functionality (any TTY type stuff
> really) that I would like to be able to handle. I would also like to
> be able to use this editor as the core for a Lisp IDE. Emacs seems to
> be a good model. I haven't studied Emacs sources either, nor do I
> know ELisp.
You would probably be better off using CLIM as the core of the IDE and
have the editor be just another CLIM pane.
> If I move on this, I will initially target OpenMCL and the Carbon API
> for the UI on OSX. Keeping the display logic separate from underlying
> buffer management and text editing functions is more of a hedge in
> case I feel the need to go with another Lisp (like SBCL on Linux or
> whatever). I also want to be able to do the text handling stuff
> before I worry too much about the UI.
If I were you, I would work on Portable Hemlock instead. As others
have pointed out, what you are trying to do is a pretty huge task (as
in you will most likely never be able to finish it, or even to get it
to a somewhat useful state). Starting with an existing implementation
of CLIM such as McCLIM and with a working (though in need for some
maintenance) implementation of the editor such as Hemlock would be a
lot easier. You are of course free to do what you want, but it would
probably be more useful to yourself and others if you would help out
with the Portable Hemlock project.
--
Robert Strandh
>
> If I were you, I would work on Portable Hemlock instead. As others
> have pointed out, what you are trying to do is a pretty huge task (as
> in you will most likely never be able to finish it, or even to get it
> to a somewhat useful state). Starting with an existing implementation
> of CLIM such as McCLIM and with a working (though in need for some
> maintenance) implementation of the editor such as Hemlock would be a
> lot easier. You are of course free to do what you want, but it would
> probably be more useful to yourself and others if you would help out
> with the Portable Hemlock project.
>
Writing a text editor need not be such a huge task.
Limit your ambitions.
Most successfull programs started out small and were then added to.
I would start out with basic CUA compliance.
A gap editor. Displaying lines correctly on screen.
Text insertion and deletion. Cut, copy and paste.
(I havn't acually done this since about 1990 and in C++)
If I were happy with the result I would add support for a regexp
library (CL-PPCRE perhaps).
On top of this I would write syntax highlighting.
The key in lisp is that you have a underlying language to write
editor macro's in.
I agree that the main benefit of creating you own editor is the
educational value.
To make it a one man project ambitions must be limited.
(OK.. If you wan't to compete with emacs it is huge.)
Now writing a word processor.. That is a huge undertaking.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
You should take a look at the Tcl/Tk text widget. It offers the ability
to assign to each character or string any kind of formatting, like font
and color, and even define events on text parts. Furthermore it allows
to embed graphics into the text. While offering this complexity, it is
quite efficient, as far as I used it, so their implementation strategy
might be something worth to study.
If you want to toy around with it (and perhaps use it as display for
your first experiments) the Ltk package is of course the obvious
starting place :)
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Thanks for your replies, folks.
I had never even heard of a gap editor before. I found this chapter
most interesting so far (I haven't read everything yet):
http://www.finseth.com/~fin/craft/Chapter-6.html
The straight up gap buffer looks very tempting but OpenMCL has some
array limits that are smaller than I would like (from (apropos
'array)):
ARRAY-DIMENSION-LIMIT, Value: 16777216
ARRAY-TOTAL-SIZE-LIMIT, Value: 16777216
I imagine most text files as (type (unsigned-byte 8)) would fit in
this space, but I prefer a larger limit. So I am leaning towards the
paged gap buffer approach. It does make things a bit more complicated
though. I've also found that I need to look harder at what Common
Lisp can do with arrays. I haven't decided yet whether pages should
be in a double-linked list or in an array.
At least I see some hope in keeping the underlying buffer
implementation separate from any display logic. Undo/redo type logic
looks like it would be interesting though. I don't think that is
something that belongs in the underlying buffer.
I am gaining an even deeper appreciation of GNU Emacs' sophistication.
I'm sorta glad I'm not trying to go there. Yet.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> I've been giving some thought to writing a text editor in Common
> Lisp.
[...snip..}
Whenever I see this thought aired I can't help but think that a
possible way to getting all the emacs packages ported to common lisp
would be to integrate ECL into GNU emacs. Anybody have any idea how
hard that would be? Once you had a full CL implementation available in
emacs, you could live in emacs and still hack your favourite packages
in CL, like slime or gnus. Build up enough of those and you might get
enough pressure built up to reimplement the core of GNU-emacs in
portable CL. Drop the elisp, and hey presto ! CL-emacs !
This is actually a strategic plan for how to get to the holy grail of
a CL-emacs.
(I realize that the OPs angle might be more
educational/entertainment-value, which makes this off-topic, but still
.. )
--
H�kon Alstadheim, hjemmepappa.
H�kon Alstadheim wrote:
> Whenever I see this thought aired I can't help but think that a
> possible way to getting all the emacs packages ported to common lisp
> would be to integrate ECL into GNU emacs. Anybody have any idea how
> hard that would be?
It would not be terribly difficult. I actually played with it long ago.
It was supposed to be a three-step process:
1) Change the garbage collector of EMACS to be a one compatible with ECL.
2) Add the internal data structures of EMACS to ECL as primitive types,
replacing some types when appropiate (for instance use CL vectors
instead of EMACS's, etc)
3) Write a elisp->CL translator. Actually it would suffice to write a
elisp->ECL bytecodes compiler.
I got as far as (1), building Xemacs with the Boehm-Weiser garbage
collector, plus some of (2), but I run out of time, and realized this
should really either a cooperative effort or a funded project.
BTW, from playing with the code, it would be substantially easier to
embed ECL into Xemacs, than into emacs. The code of the first one is
much clearer.
Regards,
Juanjo
"Juan Jose Garcia Ripoll" <·········@yahoo.de> wrote in message
····················@uni-berlin.de...
> 3) Write a elisp->CL translator. Actually it would suffice to write a
> elisp->ECL bytecodes compiler.
Here's a basic question.
How would one implement the (interactive ...) form in CL?
(defun multiply-by-seven (number) ; Interactive version.
"Multiply NUMBER by seven."
(interactive "p")
(message "The result is %d" (* 7 number)))
Turn (defun ...) into a macro within an EMACS package that is aware of the
interactive form? (interactive ...) is more like a DECLARE it seems to me.
So I was just curious how folks would address something like that.
Regards,
Will Hartung
(·····@msoft.com)
From: Christopher C. Stacy
Subject: Re: Writing a Text Editor in Lisp
Date:
Message-ID: <ubrfrpgld.fsf@news.dtpq.com>
On the general subject of implementing Emacs in Lisp,
I'd like to mention a couple of general papers that
prospective developers ought to read.
1. "The Craft of Text Editing --or-- Emacs for the Modern World"
by Craig A. Finseth. Springer-Verlag 1999; now available
online (only) at <http://www.finseth.com/~fin/craft/>.
This book is essentially an updated version of his 1980
BS thesis at MIT that was entitled
"Theory and Practice of Text Editors, or, A Cookbook for an Emacs,"
LCS Technical Memo TM--165.
2. "Emacs Lisp in Edwin SScheme", Matthew Birkholz 1993 MIT BS thesis.
<ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-1451.pdf>
"The MIT-Scheme program development environment includes a general-purpose
text editor, Edwin, that has an extension language, Edwin Scheme. Edwin
is very similar to another general-purpose text editor, GNU Emacs, which
also has an extension language, Emacs Lisp. The popularity of GNU Emacs
has lead to a large library of tools written in Emacs Lisp. The goal of
this thesis is to implement a useful subset of Emacs Lisp in Edwin Scheme.
This subset was chosen to be sufficient for simple operation of the GNUS
news reading program."