MacroLanguagePower

HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences

Difference (from prior major revision) (minor diff, author diff)

Changed: 20c20
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.
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.

Changed: 22c22
By the way, I define InternalVariables and InternalAPIs because some TextEditors use variables even though it is sufficient to provide getters/setters to manipulate internal state. The Extract command in XEDIT for example meets this standard.
By the way, I define InternalVariables and InternalAPIs because some TextEditors use variables even though it is sufficient to provide getters/setters to manipulate internal state. The extract command in XEDIT for example meets this standard.

Changed: 27c27,28
:I would say that if the syntax of calling a macro is the same as that of calling a built-in command, there is little difference between Level 4 and Level 5.
:I would say that if the syntax of calling a macro is the same as that of calling a built-in command, there is little difference between Level 4 and Level 5. For instance, several of the "commands" (primary and prefix) that are provided by XEDIT are actually macros, but there is no way to tell from the way they are invoked; if it wasn't for the Reference Manual pointing them out, users would never know.
:An impressive add-on macro is [XCOL], which does a lot more than any other block-mode text manipulation tool that I've ever encountered. It's really hard to believe that it's not a built-in command. --JLTurriff

Changed: 31,34c32,33
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.
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.

Changed: 44c43
Some editors, like XEDIT, take on entirely different personalities when all of the major KeyChords are bound to new functions. The file manager FiLELIST? exists as a set of new bindings and macros.
Some editors, like XEDIT, take on entirely different personalities when all of the major KeyChords are bound to new functions. The CMS file manager, FiLELIST exists as a set of new bindings and macros.

Changed: 52c51
language more powerfull. In theory, once the language is turing complete and the api to the editor is extensive
language more powerful. In theory, once the language is turing complete and the api to the editor is extensive

The relative power of a TextEditor's MacroLanguage is a common point of conflict.

Beyond the pedantic discussions of TuringMachines?, clearly, there are definitely different classes of MacroLanguage capability.

Power Levels

Level 0
Abscence of a macro language is the least powerful, providing no ability to extend the editor other than recompiling the program as a whole.

Level 1
MacroRecording 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 allow BindingKeystrokes? to a MacroRecording. Some editors (e.g. X2 allow the recorded keystrokes to be written to a file to create the template for a macro.

Level 2
Provision for looping and conditional execution.

Level 3
Access to InternalVariables as well as InternalAPIs.

Level 4
The ability to define variables and functions.

Level 5
The ability to define new language constructs and apply them to the editor.


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 provide 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?)

-- RonPerrella

I would say that if the syntax of calling a macro is the same as that of calling a built-in command, there is little difference between Level 4 and Level 5. For instance, several of the "commands" (primary and prefix) that are provided by XEDIT are actually macros, but there is no way to tell from the way they are invoked; if it wasn't for the Reference Manual pointing them out, users would never know.
An impressive add-on macro is [XCOL], which does a lot more than any other block-mode text manipulation tool that I've ever encountered. It's really hard to believe that it's not a built-in command. --JLTurriff

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.

--Pardus


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

As for the existence of level 3, it is there to handle those MacroLanguages that don't have a lot of power. For instance, the one in UltraEdit.

Some editors, like XEDIT, take on entirely different personalities when all of the major KeyChords are bound to new functions. The CMS file manager, FiLELIST exists as a set of new bindings and macros.

-- RonPerrella


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

-- Pardus

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.

--RonPerrella


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.

--DMcCunney


HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences
Edit text of this page | View other revisions
Last edited February 23, 2021 11:04 pm (diff)
Search: