History of development and key concepts of Orthodox Editors

Dr. Nikolai Bezroukov

Version 0.81 (March 27, 2015)

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

Introduction

• Orthodox Editor Definition
• Two Families of Orthodox Editors

Notion of Orthodox interface

Eastern Orthodox Editors

• The most important innovation:  Folding

• The most important innovation 2: Usage of a standard scripting language (REXX) as a macro language

Western Orthodox Editors

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

• The most important innovation 2: Concept of Editor Buffer Piping

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:

• Eastern Orthodox family represented by such editors as XEDIT, Kedit, THE. All of them use REXX as a glue macrolanguage. All of them support folding which the second important feature typical for this category of editors
• Western Orthodox family represented by vi and its derivatives with VIM as the top representative of the category. They are characterized by extensive support for regular expressions and ability to pipe the editing buffer through external filters.  The letter is the key advantage as it provides the unique and unmatched ability to use Unix utilities and shell scripts as an extension of the command set. Some of them (VIM) also support folding. They often have ad-hoc macro language (primitive in VI, better but still ugly in VIM)

We define the notion of  "orthodox editors" as having the following distinct features:

1. They have a well-defined command set that is comparable in power to GUI based commands and command line can be used to enter editor commands. For some of them (vi - line ) that comes naturally, from the fact that they were initially designed for typewriters. 
2. They permit doing any editing task using keyboard  (although mouse can speed up or simplify many of those tasks and is not rejected in the extremist way)
3. They use a standard scripting language as a macrolanguage (TCL, REXX) or unique for the application (YASL  - yet another scripting language) like in vim 6 as a macrolanguage. It serves as a glue for the command set implemented by the editor. With some reservations we can accept  a unique for the application (YASL  - yet another scripting language) like in VIM. This is definitely less attractive solution as it is difficult to master the language that you use only for a specific application (in this case an editor).  The same consideration is applicable to Emacs. 
4. They support folding (all command in XEDIT and its derivatives; folding capabilities in VIM )
5. They distinguish between editing buffer and the windows in which this editing buffer is displayed allowing multiple windows to display the same buffer.
6. They support regular expressions
7. They permit processing selected part of the editing buffer or all the buffer via pipe connected to external command (! command in vi)
8. They support multiple views of the same editing buffer.
9. They allow piping in output from arbitrary pipe into the current position of cursor, selection, or all buffer as well as exporting a selection or all buffer as an input stream for an arbitrary pipe.  

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

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 editors for programmers providing despite Spartan interface rich functionality absent in almost any other editor with possible exception of vi and its derivatives. Despite integrating a macro language they are actually pretty small, mid-weight by some standards (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: 

• Eastern orthodox editors introduced
  • folding (all command in XEDIT)
  • Usage of a standard scripting language as a macro language (REXX).  
  • Multiple views of editing buffer
  • Ability to bind execution of a command on the command line to the selection on the screen
• Western Orthodox editors have command set of ex editor. They introduced
  • regular expressions as a powerful editing tool
  • extremely powerful concept of editing buffer via Unix pipes; the latter is still mostly missing in most other advanced editors.
  • The idea of two command channels: channel to internal interpreter (":" commands) and channel to OS shell ("!" commands).

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

• There is a deep interconnection between OFMs and Orthodox Editors. Actually OFM can be implemented on the base of EOE and VM/CMS actually contains a file manager that is XEDIT-based.

• There is a subtle similarity between XEDIT family and VI family,  those two seemingly unconnected families of editors one originating at East Coast and the other in West coast (that's why I used names Eastern Orthodox and Western Orthodox for them ;-).

Actually the second point was the main reason that I 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 (that goes with Ph.D ;-), 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).

In other words those tools are second representatives of a different approach to GUI interface then Apple GUI or Microsoft GUI (which are converging). Interface that can be called "Orthodox Interface" and which originated in Xedit, vi and NC.  And this Spartan interface with ancient-looking, "half-baked" GUI with command line present at the bottom of the screen give users important and unique capabilities that are missing in other similar "pure GUI" Tools. And those tools survived despite all odds because they are capable of giving advanced users the ability to achieve an extremely high productivity, beating competition. 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 worse, primitive editor such as Pico just because it's simple to learn. It's like settle for life to use Basic.   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:

• Support of folding (all command in XEDIT and its descendants)
• Support of standard macro language (REXX in case of XEDIT and its descendants)
• Regular expression support outside of simple searches
• The ability to process the editing buffer using pipes

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

• Deep interconnection between OFMs and Orthodox Editors. Actually OFM can be implemented on the base of EOE and VM/CMS actually contains a file manager that is XEDIT-based.
• Subtle similarity between XEDIT family and VI family,  this seemingly unconnected families of editors

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:

• Command line interface is available and it should be possible to enter all (or most) editor commands using command line interface.  This is the first and the most important requirement.

• Console version should exist and should be as usable as GUI version; Despite substantial progress with availability of GUI based interfaces, our world is still imperfect and the value of console version in remote editing could not be underestimated.

• There is a distinction between buffers (that contain files) and windows (that display parts of buffers)

• All commands should be enterable from the keyboard although that other methods of entering commands can be available (mouse, menus, etc.). But full keyboard functionality is important as it often provides for additional expressive power (although for some operations mouse can be more convenient). Full keyboard support means that at least some external scripting (Expect style scripting in Unix) is always possible.

• Some kind of macro language is supported. Classic EOE use REXX but TCL is OK too. Interface to a common macro language along with custom macro language can probably be accepted too (like Perl interface in VIM) as they represent an interesting compromise between inclusion of the popular scripting language like TCL or REXX and the size of the editor.

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:

• Eastern Orthodox Editors (THE, XEDIT, Kedit, etc.)  Those are derivatives of XEDIT that use REXX as a scripting language and has original and powerful folding capabilities from the very beginning (all command in XEDIT). They also has built-in command-line interface with permanently visible (or pop-up via hot key) command line window. 

• Western Orthodox Editors sometimes called catholic editors ;-)  (Vim6 and other some other vi derivatives). they also have command line which can be made visible by a special prefix (":").   In this case they grow up directly from non GUI editor -- ex

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 (Yet another scripting language) development. There are also some interesting links between  Eastern Orthodox Editors and  Orthodox File Managers.

Notion of Orthodox interface

Orthodox interface is the interface that has both command line interface elements and GUI interface elements glued together.  As cynics would say this is a half-baked GUI-interface and this statement definitely has some truth as at least one of them  emerge during attempts to convert previously pure command line tool to GUI (text terminal GUI) mode: this was the case with vi which was text terminal GUI extension of ex editor.  Apple and Microsoft GUI interface attempt to hide from us the internal command that you mouse gestures are generating, while orthodox interface attempts to expose it.

In Orthodox interface there is always a set of commands that exists as a language with text  names for functions and parameters and glued together by control structures. Special keys and key combinations as well as mouse buttons and mouse gestures are just shortcuts to this basic set of commands. So interface is split into two parts:

• Generation of internal commands via GUI

• Execution of generated internal command by internal language processor.

This existence of formal internal language is the most distinctive feature of orthodox interface.

And this idea was invented and reinvented by so many people that it looks like this is a new different type of interface, distinct from Apple-Microsoft interface.

For example this is true for various OFM, for orthodox editors such as vi or XEDIT like of editors (Edit, Kedit, THE, Slickedit), for GNU screen, smith in AIX and many other programs.  Those tools were from the beginning designed is a way that allow coexistence of command line with GUI interface. So in a way Orthodox interface is all about co-existence of two principal forms of computer interfaces in a single program by using command line as the focal point. 

That means that we can look at orthodox interface as a compiler of GUI "gestures" into regular command language with text representation. Those generated statements of this command line language are executed to achieve the desired effect.

We can also introduce idea of channel: each channel forward generated or manually written commands to specific processor. For example we can thing about vi as having two command channels: one is ": channel" (internal commands channel) which process commands directed to editor buffer and another is "! channel" (external commands channel) which direct commands to OS with the possibility of using all or part of editing buffer as input as well as to modify all or part of the editing buffer using output of executed in OS command of complex pipe. 

In OFMs this is implemented differently: there is a single "OS command channel", but there is not distinct "internal command language", althouth some OFMs recently moved in this direction.

All-in-all I am convinced that the notion of Orthodox interface as an interface distinct from and based on different principles then Apple and Windows GUI interfaces (which are actually became much closer with time). As such this is a much wider phenomenon then either OFMs and orthodox editors such as vi and THE (orthodox editors),  windows multiplexers (GNU screen), windows managers (such as ratpoison).

I am still working on refining this notion but as a set of  ideas it definitely includes three following notions:

1. Extensibility and programmability (with shell and/or scripting languages) are key to enhancing productivity of advanced users and as such they should have much higher priority for designers of the interface then chrome.  This "the ability to program as second literacy"  paradigm (see  Ershov1972 ) inherent in orthodox interface is actually radically different design paradigm than the one used in classic Apple-Microsoft GUI with their emphasis on "users" and  multicolor eye candy with gradient colors icons and fancy animations.
    
2. Orthodox GUI is a "visual shell".  Like classic Unix shells, Orthodox GUI should have least one "command channel": ability to type statements in some formal language which, when executed, change the state of GUI. In other words they implement what can be called "command line controlled GUI". It can be just "external" command channel where commands  go directly to OS (like in OFMs), or internal command channel where commands are processed by internal interpreter (for example REXX or Lua) and reflected on the part of editing buffer that is displayed as in orthodox editors, or some combination of both. Commands that are entered into command channel are executed immediately like in shell and the result is immediately reflected in GUI interface. They can be glued into complex scripts by some ad-hoc or (preferably) standard scripting language like REXX or LUA.
    
3. Elements of  automatic program generation with the help of GUI.  Another way of looking on orthodox interface is to assume that GUI "gestures" in it first are compiled into some command line language and that those generated statement are executed by command processor and cause corresponding changes in GUI screen. That means that we can (and probably should) look at orthodox interface as a compiler of GUI "gestures" into regular command language with text representation. Those generated statements of this command line language are executed to achieve the desired effect.

   GUI can also be used in supplementary role to generate part of command line construct that are written by the user on the command line by inserting certain elements via macros or shortcuts like (Ctrl-Enter, Ctrl-[ and Ctrl-] in OFMs) and any other creative way. Generally in OFMs you can "assemble" pretty complex commands from elements of GUI (and freely move within directory tree in a process without destroying it, the capability that was always a desirable part of Unix command interface)

   Recently those ideas related to vi and orthodox editors started cross-pollinated OFM that consider themselves not derivatives of Norton Commander, but derivatives by  vi  See ranger and vifm. have some interesting, distinct from traditional "Norton" line of OFM ideas implemented.

There are also some other common features but they just overlap and extend the three more fundamental features listed above:

1. Tiled, nonoverlapping windows with minimum decorations. Generally both Orthodox editors and Orthodox file manager feather rather Spartan interface.
    
2. Stress on availability of all commands via keyboard, not only via mouse clicks, althouth mouse can be productively used and is widely used in such interface. In this sense claim that such interfaces are "mouse-less" is completely untrue. Simply mouse plays the role of important but supporting instrument, not as the primary instrument as "drag and drop" type of interface. 
    
3. Stress on availability of macrogenerator. This is connected with viewing shortcuts as the means to generate some internal commands.
    
4. Stress on the ability to utilize pipes and external program as a source of gui elements. This is especially visible in vi with its ! and !! commands. Ability to redirect output of commands executed in one window to other windows and processes. That includes the ability of forwarding result of particular command execution into panel in OFMs (panelize command in OFMs, especially external panelize command in Midnight Commander) and capability of ! command to use part of editing buffer as input and pipe the result into selected part of editing buffer in vi. For example, the command:

   :1,$!indent

   will beautify your program using standard Unix beautifier (indent). This is a classic example of using piping in vi.
    

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 one flavor 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

• Slicing (as implemented in EOE's classic command All) this is the most essential feature. Slicing was first implemented by Xedit, the grandfather of Eastern Orthodox Family of Editors. All members of the family (almost a dozen currently) have "all" command. It provides for selective pattern-based slicing (substring-based -- classic Xedit or, better, regular expression based -- THE) with the capability of editing this folded representation. Underling mechanism of selective display is very powerful and can be adapted to outlining based on indent or header-based MS Word-style outlining (see below). As slicing is completely controllable via macro language I never saw a capability of equal power in other editors (Slickedit has somewhat similar feature, under the name of "The Selective Display" dialog, but not exactly and it used proprietary macro language not REXX or other standard macro-language and does not have a command line interface to this feature).  Currently VIM6 supports slicing (all command can be implemented via macro).
   

• Outlining -- hierarchical view of the file either in the same windows. Out of the early (and the most influential) editor  that implemented this feature was MS Word: I remember that MS Word 4 (1987) already has this feature. Outlining can be implemented using a separate directory-like windows like in Origami as well as in some modern HTML-editors. A simple versions of outlining can be implemented via slicing. Opposite is not true. Please note that nesting-based outlining as in MS Word is too rigid and not as useful as a substitute of folding, although with careful planning of levels one sometimes can achieve similar functionality. At the same time tag based outlining is actually a very powerful and useful feature.
   

• Chunking and dynamic pseudo-hypertext annotations (the ability to view several relevant parts of the same or other file as a set of adjacent windows. For example, all function calls in one windows and the function body in the other, adjacent window. Or documentation to the function in a windows adjacent to the function code, etc.
   

• Windows Linking -- the ability to have multiple views of the same file as implemented in all decent editors. This is actually the most widely available surrogate of folding (poor man folding). On a logical level it involved distinguishing between buffers that contain files and windows that display buffers -- the important orthodox editors feature that we mentioned before. It is possible to perform some powerful (and non-trivial or not possible in regular editors) operations, for example rotate buffers in windows like you can do in VIM6, if you distinguish those two concepts.

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 (REXX) as a macro language

Usage of standard scripting language has distinct advantage over "vendorspeak" type of macro language used in most programming editors. The skills are transferable and that stimulates deeper learning of the language while with vendorspeak skills are limited to the editor environment which typically is not sufficient incentive to study it deeply and keep your knowledge current.

Because EOE uses a standard scripting 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.  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 maintenance 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:

• No built-in scripting language (like REXX in  eastern orthodox editors or LISP in Emacs). This make VI less attractive for power users. VIM added Perl language support that partially compensates this shortcoming.

• Several modern concepts like shift-arrow highlighting of blocks, outlining, comparison in vertically split windows were absent. VIM6 added most of those features...

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

• Less is More: A rich functionality behind Spartan interface of Orthodox File Managers
• Nikolai Bezroukov A Note on Size-based Classification of Text Editors
• Softpanorama Orthodox Editors Page
• Eastern Orthodox Editors (XEDIT/KEDIT/THE, etc)
• Softpanorama Western Orthodox Editors Page: VIM -- Folding VI-style Editor
• Softpanorama Program Understanding Page

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019