Softpanorama
May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Latest Last year Top visited Scriptorama

Orthodox Editors

Dr. Nikolai Bezroukov

Version 0.62

Copyright 1998-2011, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.

Introduction

Orthodox Editor Definition

Two Families of Orthodox Editors

Eastern Orthodox Editors

Western Orthodox Editors

Webliography

Abstract

This paper tried to introduce a new concept: orthodox editors as a special category of editors. All of them have command line set of commands and respective glue macrolanguage. We have found two such families:

We define the notion of  "orthodox editors" as having at least three distinct features:

This article is a modest attempt to create a basic classification useful for further studying this important class of editors. The author argues that this class of editors can serve as viable mid-weight editors for programmers (see a companion paper A Note on Size-based Classification of Text Editors for this further discussion of related ideas).

Please note that both subclasses of orthodox editors were pioneers in introducing several important for any modern editor features, features that unfortunately still are absent or poorly implemented in most other editors:

This paper explores two sets of  deep interconnections that were previously unnoticed in the literature:

Actually the second point was the main reason that decided to use a superclass term "orthodox editors" that includes as subclasses both XEDIT editors line and VI editors lines. Not only because I like to invent new terms, but I really see deep similarities between them and their connection to a similar phenomenon that I studied earlier in case of File Managers (see OFM page for details): all this tools give users the ability to achieve an extremely high productivity both in GUI-based and  non-GUI environment. Although some design decisions in those editors were dictated by limitation of old hardware they withstand the test of time and proved to be useful and extremely productive tools for modern environments.

Introduction

I abhor a system designed for the "user", if that word is
a coded pejorative meaning "stupid and unsophisticated".
-- Ken Thompson
 

I would like to stress that an editor is probably the most important tool for programmers, therefore one needs to choose it wisely. A popular consideration that easy to learn editor (for example Pico or Notepad) is the best does not withstand any critique. An editor is too important tool for programmers to settle for the basic capabilities and it's a big disadvantage to select a mediocre or even primitive solution just because it's simple to learn.  Any professional programmer needs a professional editor.

Any professional programmer needs a professional editor

In case you are a casual user simple editor might make sense, but still lack of  growing space is a disadvantage.  But for everybody else this is one of the most serious mistakes that you can make -- a mousetrap to avoid. You do need a powerful editor or you will regret your choice the rest of  your professional career (that in case you will be able to switch somewhere during active phase of your career; otherwise you have pretty good chances to die in happy ignorance ;-).  Bad habits are difficult to change and usage of a primitive editor is such a bad (and pretty widespread) habit.  Naive tales like "How I like Pico (or Notepad)" are amusing the same way as stories about people who voluntarily deprive themselves of basic staff and enjoy this state of deprivation.

The main problem that I see is that people tent to stick to whatever editor they got used to first and even became emotionally attached to the "first choice". It happened to me and it took me a lot of efforts to move from a primitive editor to a decent one. Often this "first choice" is a pretty mediocre editor that is/was widely used in a particular environment, but that not necessary is able to provide high performance in all typical editing tasks.

The author argues that programmable editors are worth studying like programming languages and a powerful editor is huge advantage from the point of view of reaching high productively (and avoiding many typical frustrations).  In this paper I would like to draw an attention to two old but still viable programmer editors that I included in a broad class of Orthodox editors.

Please note that both subclasses of orthodox editors were pioneers in introducing several important for any modern editor features, features that unfortunately still are absent or poorly implemented in most other editors:

This paper explores two sets of  deep interconnections that were previously unnoticed in the literature:

Actually the second point was the main reason that decided to use a superclass term "orthodox editors" that includes as subclasses both XEDIT editors line and VI editors lines. Not only because I like to invent new terms, but I really see deep similarities between them and their connection to a similar phenomenon that I studied earlier in case of File Managers (see OFM page for details): all this tools give users the ability to achieve an extremely high productivity both in GUI-based and  non-GUI environment. Although some design decisions in those editors were dictated by limitation of old hardware they withstand the test of time and proved to be useful and extremely productive tools for modern environments.

Orthodox Editor Definition

I will call the editor Orthodox if  and only if:

Both Orthodox File Managers and Orthodox Editors are descendants of some very old implementations with unique features that were not preserved by most more modern and more fashionable editors that replaced them.

Two Families of Orthodox Editors

We will distinguish between two families of orthodox editors:

There are some important common features in those two families despite the fact that REXX is full-fledged scripting language while VIM-macro language is an ad-hoc (and pretty limited) YASL development. There are also some interesting links between  Eastern Orthodox Editors and  Orthodox File Managers.

Eastern Orthodox Editors

The level of sophistication of command line interface in EOE is pretty high and I would argue that a professional can achieve in this environment a higher productivity than with any editor that relies mainly on mouse and menus.  This family is probably the oldest production-level folding editors in (XEDIT seems to be around on VM/CMS from late 80th) in existence and it still in wide use. 

The initial version XEDIT was released by IBM in late 1980 and as Melinda Varian (Princeton University) wrote in her very interesting history of VM "There can be no question that by releasing XEDIT in 1980, IBM gave CMS a new lease on life". Here is the quote from her very interesting paper ( I strongly recommend to read at least the beginning of this 73 pages paper -- it provides new insights into how two most interesting operating system Unix and VM/CMS were influenced by Corbato's CTTS and MIT Multix project):

At the same time, we started seeing the results of IBM's new commitment to VM. VM System Product Release 1 came out late in 1980. VM/SP1 combined all the [B]SEPP function into the new base and added an amazing collection of new function (amounting to more than 100,000 lines of new code): XEDIT, EXEC 2, IUCV, MIH, SUBCOM, MP support, and more. There can be no question that by releasing XEDIT in 1980, IBM gave CMS a new lease on life. Within no time, programmers and end users were building large, sophisticated applications based entirely on XEDIT, stretching it to its limits and doing things with it that IBM had never envisioned. That they were able to do that was a tribute to XEDIT's author, Xavier de Lamberterie. 130 (If you've ever wondered where the ``X'' in ``XEDIT'' came from, now you know---it was Xavier here.) It was also fortunate that those XEDIT macros could be written in the new language EC 2, which was considerably faster and more powerful than VM's original EXEC processor. The author of EXEC 2 was Chris Stephenson, of IBM Research.


------------------------------------------------------------
130 When asked what other editors influenced the design of XEDIT, Xavier graciously replied with the following note (X. de Lamberterie, private communication, 1989):

Well, XEDIT comes from a long way. It has been influenced by the editor from CPˇ67, then some other editors that were developed locally at the Grenoble University (including editors with macro capabilities, which were probably the first ones to have such a concept), and certainly from Ned that we had a long time ago (some XEDIT target commands are inspired from Ned). Then later on, when full screen displays were available, XEDIT took some ideas from Edgar and ISPF (features like prefix line commands).  But I guess the major feature of XEDIT was to keep the "heart'' relatively small and allow users to redefine and/or extend the existing commands via EXECs or REXX macros. This was one of the major successes of XEDIT.

Members of this family of editors are best known to users OS/2, VM/CMS and users of TeX . Even some flavors of DOS used to have such an editor: IBM DOS 7.  Inside IBM developers had access to epm (derived from e / e3 / peII / tiny etc). My understanding on epm is the author of  epm left IBM and started (with others) Visual SlickEdit.

I consider folding (actually there are several types of folding -- the one implemented in EOS is usually called  slicing (in most EOE it is implemented as command All).  The second important type of folding  is outlining as implemented in MS Word and other word processors as well as in best HTML-editors) -- also an extremely useful feature. Once you have got used to the folding paradigm, you will not want to use a flat editor again! See also the main page that probably can help you to understand why folding is so important.

All members Eastern Orthodox Editors family use REXX as a scripting language, but this is not principal feature --  conversion to TCL seems possible and even desirable, especially for THE.  

THE is GPLed editor and probably is as portable as Emacs. The unique feature of this category of editors is so called selective editing or slicing. All members of the family (almost two dozens actually, if you count all implementations) have all command. It  that provides for selective pattern-based slicing of test based on regular expression with the capability of editing. Underling mechanism of selective display is very powerful and can be used for outlining. I never saw similar capability in other editors.

Among commercial editors Slickedit has a very similar feature, under the name of The Selective Display dialog. It uses ad-hoc C-style macro language instead of REXX. This language, called Slick-C, is the actual implementation language for the editor. Almost all editor is written in Slick-C and the binary code is just the Slick-C interpreter.

The most important innovation 1:  Folding

I consider folding a very important feature of any programmer editor, the feature without which programmer is unable to achieve the highest productivity and job satisfaction possible. Actually there are several types of folding

Folding is a special case of program abstraction and as such is linked to program understanding issues. There are some interesting research ideas relevant for this topic. Based on the results in this area it's evident that pure syntax-based folding (or it's indenting-based surrogates) are too rigid and not that useful and why simple all command in Xedit style editors is such a flexible and powerful tool that  in many cases beats more "program navigation" systems.  

Most users who were exposed to the folding paradigm valued it so high that they are ready to experience some disadvantaged by adopting an editor that support it. Most never want to use "a flat editor" again! That's why, paradoxically, due to its outlining capability (and macro language) early versions of MS Word (Word 4) were used as a programming editor :-).

Although orthodox editors are one of the oldest family of editors in existence they still hold their own against competition. May programmers consider editors without command line and imbedded scripting language inferior to editors that have this capabilities no matter how much GUI frosting is present. 

This page also establish important implicit links between Eastern Orthodox Editors and Eastern File managers (I suspect that the first implementation of the orthodox manager were based of Xedit in CMS environment. The other important link is the link between EOE and WOE or VI-style editors with folding capabilities (VIM).

In this page I will mainly concentrate  Eastern Orthodox Editors  or EOE editors (Xedit was originated in IBM and as everybody knows IBM is on the East Coast).

The most important innovation 2: Usage of a standard scripting language as a macro language

Because EOE contain a scripting language (or scripting language alike) macro language, orthodox editor community developed a lot of interesting macros, much like Emacs community.  Please take a look at  THE macro contributions from users...

Western Orthodox Editors

The important thing to understand is that like Xedit-style editors VI is also an editing philosophy (set of ideas of how editor should be), not only the implementation. And this philosophy is quote different from the mainstream GUI editors. That's why Windows users usually have so many problems mastering vi. That also means that there can be and actually are implementations that are much better than the original vi, but that adhere to the same philosophy.  One of such implementations is VIM and in starting form version 6 it is a very powerful editor that satisfy the requirements of the orthodox editor and can be considered as a representative of a new, different family of orthodox editors -- western orthodox branch, You can call it catholic editors, if you wish :-).

Despite its Spartan appearance (actually not that Spartan in the VIM GUI-based version for Windows ;-)  vi contains some unique ideas and while the initial version of vi have had no scripting language at all if was definitely written in the same spirit of attention to command line that is characteristic for  Eastern Orthodox editors (VM/CMS Xedit, THE, Kedit).

Due to its Unix roots VI has unique features that other editors do not have and some non-Unix editors cannot have in principle (due to absence of OS support for them). Actually some of these features can never be found in Windows-style editors. Among the most importa unique features of vi:

  1. The idea of access to buffers via pipes -- really great and even today pretty novel idea that is essentially absent in any other family of editors that I know. This ability was extended in VIM to the ability to use Perl for operations on the buffer.  Here VI was a real pioneer and just for this feature alone we can forgive a lot of shortcomings...

  2. Use of regular expressions. The precursor of VI Ed pioneered use of regular expressions in editing and this is still probably one of the best support of regular expressions (a feature that until recently was a weakness of Eastern orthodox editors).

  3. A set of the command line commands (this is an essential feature of orthodox editors. Unfortunately the set of commands taken from ex is far from being perfect and can benefit from modernization.

  4. The ability to invoke any shell command from the editor (! escape on the command line). That means the ability to construct arbitrary complex pipes and then access the results.

  5.  

    6. Text-buffer execution, which operates only in command mode: once text has been placed in any of the named text buffers, that text can be executed as if it were a sequence of 'vi' commands.

  6. A pretty idiosyncratic but very interesting idea of two modes -- command mode and text mode. The fact that editor survived is an implicit confirmation of the fact that this idea help to perform some class of tasks. In some respect I suspect that this feature provides an implicit "mini command line":  the possibility of creating short sequences of commands that perform a particular function at the current location. Such sequences sometimes has internal logic (like in dd -- delete line; dw -- delete word, dc delete symbol, etc) that simplify memorizing them. That means that like orthodox file manages users, power VI users eventually acquire piano player like motor skills for performing typical tasks, especially configuration files mainenance tasks.  As one researcher put it (cited in There is A Perfect Editor):

    Experienced emacs and vi users, who use their editors to write and edit English text, performed a series of basic editing tasks and wrote a movie or book review. Our findings suggest that moded editing, as exemplified by the vi editor, may be preferable for fixed editing tasks, while modeless editing, as exemplified by the emacs editor, may have some advantages for free composing.

I believe that it was VIM 6 that opened the possibility of usage of vi as the standard mid-weight editor for programmers. Old vi implementations deprive the user from a significant subset of functionality that should be typical for mid-weight editors. In this sense VIM6 is the first really decent implementation of VI editing philosophy. Among shortcomings of the old versions I would like to mention:

All-in-all I think that VIM6 is a very interesting and very convenient for some operations editor that preserved all major advantages of the original VI and removed most of its shortcomings. Let's reiterate the most important and innovative features of the original vi editor again:

Actually VI command set emulation can be an interesting test for any midweight or heavy-weight editor including THE. For example Emacs is able to emulate VI using viper package

In any case please, please do not use old implementations of vi, if it's possible to use VIM6. Please use vim6 as it supports most of the features required for a decent mid-weight editor including folding, undo/redo, Perl integration, etc. See also If you gotta use VI, use VIM. Linux Gazette August, 1995

Generally editor is usable if it satisfy the following criteria: 

  1. Users must be able to accomplish their editing task with minimal effort (that's a complex question and advanced vi users can argue that the presence of command mode increases productivity in correction of programs and configuration files, but this is not very convenient in composition)

  2. The editor must always provide feedback to the user to help him to understand what is happening. (here vi is rather bad -- there is almost no feedback in vi). 

  3. The editor should not produce any unexpected results at any point in the process (not true for the combination of windows users and vi ;-)

  4. Users should not suffer from information overload (this is the case with vi as the user need to know more than a two dozen of keys and a dozen commands to be minimally productive; this is a definite drawback, but there is no free lunch )

  5. The editor must be consistent at every point in the process. This is a (weak) argument against command mode/insert mode, but people are very flexible ;-)

For users with windows experience vi breaks rules 1-3 and 5. Anyway,  vi is default editor on Unix and even if you hate vi, you still need to learn at least the minimal subset if Vi/Vim commands. Vi knowledge is also part of Unix/Linux certification requirements. 

The most important innovation 1:
Regular expressions as an editing tool

Regular expression of an editing tool was an innovative idea 30 year ago, but now it's almost commonplace. Still the level of integration of regular expressions in command set is different between editors and most editors provide just find command that support regular expressions. vi in its command set, which is essentially ex editor command set went farther then that.

The most important innovation 2:
Concept of Editor Buffer Piping

VI and its derivatives possess a unique powerful feature that is not present in any other class of editors. This feature is the possibility of access to editor buffers via pipes. Despite being almost 30 old it still looks like a pretty novel feature, which is a sure quality of really revolutionary innovations: simple and poweful at the same time.

In VI the pipe is applied to editing buffer both as a source and as a destination. A VI pipe is thus can alter the buffer using standard Unix filters that instantly become a part of editor toolbox. This is an extremely elegant idea. The ability to pass nearly arbitrary chunks of text through any UNIX filter adds incredible flexibility  at no "additional cost" in size or performance of the editor. 

This ability was extended in VIM to the ability to use Perl for operations on the buffer.  Here VI was a real pioneer and just for this feature alone we can forgive a lot of shortcomings

Conclusions

Both classes of editors can benefit from greater awareness of the developer community about each other. Some solutions like XEDIT-style folding or VI-style buffer piping are perfectly adaptable as cross-family solutions.

Users can greatly benefit from the availability of well defined command set and glue language for it (especially standard one line TCL or REXX.  The power and flexibility achievable via command line set cannot be replicated in a pure GUI environment.

Webliography

Copyright © 1996-2012 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

Disclaimer:

Created May 16, 1996; Last modified: December 04, 2011