NoMacroLanguage? can be considered as Level 0. Least powerful. No ability to extend the editor other than recompiling the program as a whole.
MacroRecording? can be considered as Level 1. It provides the ability to record keystrokes into a macro command that can be replayed. In some editors, like the ViFamily, it is possible to repeat a MacroRecording? 'n' times. Some editors allows BindingKeystrokes? to a MacroRecording?.
Looping and conditionals could be considered level 2.
The ability to define variables and functions would be considered to be a level 4 capabiltiy.
Finally, the ability to define new language constructs and apply them to the editor would be level 5.
What I've found is that most off-the-shelf MacroLanguages? such as RexxLanguage, PerlLanguage, ElkLanguage?, or PythonLanguage that are designed to be embedded into a TextEditor allow you to achieve at least level 2. Simply allowing access to InternalAPIs? and InternalVariables? means achieving level 4.
By the way, I define InternalVariables? and InternalAPIs? because some TextEditors use variables even though it is sufficient to provides getters/setters to manipulate internal state. The Extract command in XEDIT for example meets this standard.
The only programming languages that I know that could fit a Level 5 capability would be Lisp/Scheme? variants with a (defmacro) capability as well as ForthLanguage?. But ForthLanguage? is almost never found as a MacroLanguage. EasyWriter for PC was written in ForthLanguage? but to my knowledge, had no ability to use ForthLanguage? as a MacroLanguage. (can anyone comment on this?)
Could you specify level 5 in more detail ? What do you mean with "new language constructs" ? If an editor is Perl (http://www.perl.org) programmable, you can make perl understand all kind of constructs that the perl pinterpreter doesn't understand by default. As for macros I think the one big feature is the ability to program a routine that can be bound to a key and that can modify the buffer and can interface with the internal state of the editor.
Well, both Lisp and Forth allow you to create new language constructs, not just simply new subroutines. Both languages would allow you to redefine how 'if' works, for instance. This might be useful in the context of defining new ways of scoping/looping through text, for instance. I agree that the big benefit of having macros is to be able to bind them to a KeyChord? (not just a single keystroke).
I can change how the 'if' contruct works in perl by applying a source filter. This is ugly, and probably not what you meant, but serves to demonstrate there is no clear line. Also I very much doubt whether this feature makes a language more powerfull. In theory, once the language is turing complete and the api to the editor is extensive enough the syntax of the language is a matter of taste.
For example when using the zoid readline library (this is not a real text editor but a Shell) you can bind a perl subroutine to any key sequence, and you can manipulate all internal variables of the library and modify the buffer contents from this routine. Could you give an example of a construct that one could do with such a "level 5" language, you can't with this construct ?
Arrrrggh! You used the turing completeness argument! :-)
Well, I would agree about the syntax is often a matter of taste. In fact, the Gnu boys tried to make a language that had both an ordinary syntax and a lisp-like one. I don't think they ever finished the former. My best advice about how to see the differences between lisp and other languages is to read http://www.paulgraham.com He's the guy that pretty much wrote the book on Common Lisp. Read the section on macros. It will blow your mind.
Please note: I'm not anti-perl. In fact, I'm a big fan and have used it to do all kinds of stuff.
The most powerful editor I'm aware of in this regard is GNU Emacs, because the editor *is* the macro language. GNU Emacs is essentially an interpreter for a flavor of LISP, and most of the editor is written in the dialect of LISP it interprets. If you are fluent in eLISP, you can modify the editor in any manner desired.
The thing that distinguishes LISP, as I understand it, is that *everything* is a first class object, which provides all manner of possibilities if you can get past the syntax.
There has been discussion in the Emacs community about changing GNU Emacs to use GNU Scheme as it's underlying language, but this would be a non-trivial exercise. Eric S. Raymond was talking a while back about what LISP got wrong, and comparing it with what could be done with Python. "So rewrite GNU Emacs to use Python as the underlying language", I said. "Don't tempt me!", he replied.
Ruby, designed to address perceived shortcomings in Python, would be another candidate. And I believe there is at least one editor that uses Lua (http://www.lua.org/) as the macro language. There is a language floating around called "s" (http://www.s-lang.org/) that is intended to be embedded in other programs, and an editor called JED (http://texteditors.org/cgi-bin/wiki.pl?JED) using it, too.
Emacs author Richard Stallman was a major LISP hacker in the old days when Symbolics and LISP Machines were battling for supremacy in the LISP market (see http://en.wikipedia.org/wiki/Lisp_machine#A_fork) for background), so no surprise he chose LISP as the underlying language for the C version Emacs.
The original emacs written by Stallman was also based on a macro language. Emacs began as Editing MACroS?, a package of macros for the TECO (Text Editor and COrrector) language that ran on the DEC mainframe hosting the ITS timesharing system at MIT. There is also a TECO macro called VTEDIT that makes TECO a full screen editor on something like a VT100 terminal. OF course, TECO code *does* bear a strong resemblance to line noise...
You can do similar things in TCL to what can be done in FORTH, creating new language constructs as combinations of existing ones, or adding constructs from libraries written in C. There's at least one editor implemented in Tcl, using TK for display, which could probably be extended in this fashion.
You might even talk about a Level 6. There are things like Smalltalk and Modula 3 which are "operating environments", in which the editor is not a separate program, but an embedded part of the OS, along with the language, and all OS facilities and language constructs are available in the editor context.