Lambda the Ultimate

inactiveTopic EMACS: The Extensible, Customizable Display Editor
started 11/6/2003; 3:17:23 AM - last post 11/11/2003; 12:42:37 AM
Luke Gorrie - EMACS: The Extensible, Customizable Display Editor  blueArrow
11/6/2003; 3:17:23 AM (reads: 8159, responses: 8)
EMACS: The Extensible, Customizable Display Editor
Appeal to editors, and editors you shall have!

EMACS is a real-time display editor which can be extended by the user while it is running.

Extensibility means that the user can add new editing commands or change old ones to fit his editing needs, while he is editing. EMACS is written in a modular fashion, composed of many separate and independent functions. The user extends EMACS by adding or replacing functions, writing their definitions in the same language that was used to write the original EMACS system. We will explain below why this is the only method of extension which is practical in use: others are theoretically equally good but discourage use, or discourage nontrivial use.

This classic paper by Richard Stallman describes the Emacs paradigm.

I greatly enjoy seeing how programming languages and their environments support this paradigm of writing programs while you run them, with the whole environment at your fingertips. Do you know some more good examples? Please share your favourites.

(Of course, writing programming environments is much easier today than back in the good old days, when men were men and you couldn't go scheduling in userspace code everytime somebody presses a key.)
Posted to history by Luke Gorrie on 11/6/03; 3:39:22 AM

Todd Coram - Re: EMACS: The Extensible, Customizable Display Editor  blueArrow
11/6/2003; 9:26:07 AM (reads: 785, responses: 0)
Smalltalk-80 (and its descendent: Squeak) immediately come to mind.

Forth supports the paradigm by nature. It was a quite common thing in forth to hack your own editor building it from the ground up inside of a forth session... first you figure out how to find/load "blocks" (of source), then you develop words to perform edits upon the block (often line based), then you figure out how to clear the screen on your computer, then you realize your first "display" oriented (but line commanded) editor, then you figure out cursor addressing and keystroke capture, then you do keyboard bindings to the editing words, and then you get real ambitious and try to emulate emacs...

If you are smart, as soon as you figure out how to write to source blocks, you "bootstrap" your way through the above process. If you weren't so smart, you waited until you have the full editor realized and "disassembled" the compiled words back to source which you write into the source blocks and wisely save. If you were marginally smart, you just kept saving snapshots of your forth environment (dictionary) which contained the compiled editor. If you were dumb, you'd finish the editor and type "BYE" before realizing that you boostrapped yourself but without saving your work! doh

Todd Coram - Re: EMACS: The Extensible, Customizable Display Editor  blueArrow
11/6/2003; 9:30:08 AM (reads: 779, responses: 0)
(Of course, writing programming environments is much easier today than back in the good old days, when men were men and you couldn't go scheduling in userspace code everytime somebody presses a key.)

I was pampered by TOPS-20 (twenex) where your could muck pretty well with keyboard events in userspace. It was also where I first encountered EMACS (Teco version) and "Standard" Lisp. sigh.

Ehud Lamm - Re: EMACS: The Extensible, Customizable Display Editor  blueArrow
11/6/2003; 10:54:36 AM (reads: 751, responses: 0)
This is a very nice paper on software design (and one of the papers I recommend to my students), yet I recall that when discussing programming language cosntructs the paper is a bit weak. Something about dynamic scope, right?

logarithm - Re: EMACS: The Extensible, Customizable Display Editor  blueArrow
11/6/2003; 11:53:26 AM (reads: 732, responses: 0)
While emacs is an excellent example of a programmable editor, my favorite -- vim -- is also quite programmable. quite a few things are programmed using vim's language, most notably syntax coloring and custom indenting. though it's not a lisp dialect, i found it was easier to do syntax coloring in vim than in emacs.

the best example of programming languages and environments working in tandem, i think, is LOGO.

Timothy Downs - Re: EMACS: The Extensible, Customizable Display Editor  blueArrow
11/6/2003; 4:10:18 PM (reads: 669, responses: 0)
Actually I find programmability in editors to be a mixed blessing. I often jump between computers, and often don't have a chance to bring my .emacs file with me. Still, I would never want to use an editor which was not programmable. Nowadays though I've moved over to Vim, as it has some handy *default* features I can't do without (such as %).

Luke Gorrie - Re: EMACS: The Extensible, Customizable Display Editor  blueArrow
11/7/2003; 8:26:15 AM (reads: 469, responses: 0)
Ehud: Something about dynamic scope, right?

Interestingly, the uses of dynamic scope that RMS mentions have mostly been taken over by buffer-scope ("buffer-local variables"). That is, in Emacs Lisp global variables can be shadowed on a per-buffer basis. Buffer-local variables make a particularly pleasant form of object-oriented programming, I think.

Dynamic scope is still put to good use in Emacs Lisp, though I would prefer to have lexical scope as the default. This seems to be compatible Stallman's views in the paper too, even though it's not what he says.

Mark Evans - Re: EMACS: The Extensible, Customizable Display Editor  blueArrow
11/10/2003; 11:20:45 PM (reads: 259, responses: 1)

Emacs: It's a nice OS, but to compete with Linux or Windows, it needs a better text editor.

- Alexander Duscheleit

A recent Register article on the history of vi is another curio.

Ehud Lamm - Re: EMACS: The Extensible, Customizable Display Editor  blueArrow
11/11/2003; 12:42:37 AM (reads: 271, responses: 0)
All this talk of emacs reminded me of TeX. Any good online discussion in the design of TeX (TeX is a a DSL, ain't it?)