What a text editor should do

how I see it

• My first editor was ... a card punch (and my second one too). They were of course a crude tool, but just stand to demonstrate that the first purpose of text editors is to write programs
• At the same time I also saw using a teletype attached to an HP2100 used with an editor (was it RU,EDITR ?) to enter program code

• The next experience (and the first one from a terminal) was with Electric on an IBM 360. This was a quite peculiar line-editor in which one could edit a file from begin to end, but could not go "up" unless one saved the file. I cannot remember much, but I should have still some notes on paper.
  Oh yes, here you go ...
  • the command ENTER FL=name was used to create a new file, followed by the text lines, and terminated by $$. Just the same as "modern" Unix cat >name and terminated by control-D !
  • the command APPEND FL=name was used to continue in the same way, like "modern" Unix cat >>name
  • the command MODIFY FL=name was the editor and had commands like
    • $L LN=n to list the file at line n
    • $I LN=n to input new data at line n
    • $D LN=n to delete line n
  The main paradigm is that commands were the initial letter of the English verb describing the action

• I also have only some limited recall of the editors available on the PDP, I believe one had first EDI (which was a line-editor) and later EDT which was a precursor to the VAX screen editor of the same name (I am not sure whether I used it as a screen editor, or it required a special terminal to support it, certainly I remember that some functions were optionally associated to a special keypad with a "gold key" and that I did not like that since the keys were not labelled with their functions.
  Here too I found some old handwritten notes
  • once entered EDI, one typed the file name (to create a new file)
  • then typed freely the text
  • and terminated with a carriage return to enter edit mode
  • or one used EDI filename to edit an existing file
  • in edit mode one gave commands in response to a * prompt
  • editing commands operated on a buffer in which one could move up and down from TOp to BOttom. The buffer was just a chunk of a long file, and one had to advance to a new buffer with the RENew command
  • commands were once again initial letters of English verbs like
    • L string : locate a text string
    • C /str51/str2/ : change a string into another
    • P : print current line
    • N : advance to next line (one could also combine P and N with a simple carriage return, and go back up with escape)
    • D : delete current line
    • I : input new text after current line
    • R : replace current line with new text
  I used EDI also to compose some Runoff documents, not just to write code.

• I then had some practice with IBM mainframe editors called EDIT and TED, they were still sort of line-editors. They had an "input mode" in which one could type text in full screen mode (there was even a "power input" mode which wrapped text automatically). The limitations were due to the kind of terminals. It was particularly awkward to edit on teletype-like Olivetti terminals (with fan-folding paper !), but also the majority of the other "VDU" terminals were not very comfortable.
  As far as I remember the commands were once again initial letters of English verbs similar to the ones later used with XEDIT and/or to the ones described above

• A definite step forward was made with XEDIT on IBM 3270 terminals. This was a full screen editor, in which one could use all 4 arrow keys to move on the current screen, one could use terminal-specific keys to delete a character and toggle insert/overstrike mode. One used function keys or commands to advance to the next screen (or to scroll the window displayed on the screen through the file in either direction).
  More on this editor is said below. Anyhow one should note that the typical screen was divided in 2-4 areas like here (I learned later how to configure them

  +-----+--------------------------------------------------------+
  | P   |                                                        |
  | R   |                                                        |
  | E   |                    main text area                      |
  | F   |                                                        |
  | I   |                                                        |
  | X   |                                                        |
  +--------------------------------------------------------------+
  |command line >                                                |
  +--------------------------------------------------------------+
  |PF key reminders                                              |
  +--------------------------------------------------------------+
  

  One typed (and edited using delete/insert keys) the text in the main area. One moved with the arrows among all areas. One could type any command (which were now full English verbs which could be abbreviated to one or a few letters like LOCATE, UP or DOWN, CHANGE or DELETE, etc. ) on the command line. Some commands (e.g. to delete one or more lines, or to insert a blank line) could also be typed in the optional prefix area.
  Some other commands were also associated to one of the 12 PF keys (3270 had a 3x4 special keypad) like the ubiquitous PF7/PF8 to move back and forward one screen at a time. And a reminder of the commands associated to the keys was displayed on the screen
  The paradigm on "input mode" (and "power input") was preserved, the I command extended the main text area to the full screen, and one exited by it with a double carriage return.

• At the same time I used for a short while EDITR on HP1000, which was also a sort of line-editor.
• It was soon supplanted by EDIT/1000 which made nice use of the standard HP terminals and keys and was sort of a full screen editor. It actually had two modes of operation :
  • In the first mode it operated as a line-mode editor, in which one used the more-or-less usual one-letter commands of the old EDITR. In particular I remember
    • a sequence of slashes and text could be used to change part of the current line (slashes being placeholders for characters to be left unchanged)
    • the command to replace a string of text was G/str1/str2/ which we all found quite strange (un-mnemonic) and remembered thinking that the programmer had some speech defect and pronounced Ghange instead of "change" !
  • In the screen mode, entered by command S one used the entire screen to edit text, using all 4 arrow keys to move on the current screen, using 4 terminal-specific keys to delete a character, toggle insert/overstrike mode (there was even a LED reminding one was in insert mode !), delete a line and insert a blank line.
  • The current "buffer" could extend beyond the 20-line screen (if lines in excess were added) and be scrolled within a size which was terminal-dependent (40 or 100 lines).
    When one had to advance to the next buffer one had to type a control sequence. I do not recall now the exact control sequences, but I seem to recall one had different (double or single) ones to advance saving edits or discarding them, or to exit (also temporarily for one command) from screen mode to issue a line mode command. Some of them were sort-of-mnemonic (control-F for "forward", control-P for "previous", control-S for "screen" ?)
  • EDIT/1000 also had a regular expression mode (SE RE ON which allowed to write quite easily complex "change" commands. One could even write some editing scripts using the TR (transfer, i.e. input redirection to a batch file) command.

• While XEDIT has never been perfect for what concerns regular expressions (the SET ARBCHAR ON command is great for locating, but does not allow to replace sequences of more than one piece of arbitrary text in arbitrary functions of the patterns found), it has always been simply great for scripting and had a lot of other pluses.
  • XEDIT has a lot of SET commands to control its behaviour, the layout of the screen (later even colours, but I practised it only a little on our only 3279 terminal), to define functional keys, to enable or disable the prefix area and command line and to allow particular operations.
  • the SET ZONE command allows a very easy and nice operation on columns
  • the SET VERIFY allows to view parts of very long lines (and there are also horizontal scrolling commands)
  • the ALL and SET SHADOW allows to view (and apply edits) only to lines containing (or not containing) a boolean combination of patterns
  • one can view the file in hexadecimal (HEXTYPE) and edit it inserting arbitrary hex sequences (SET HEX ON and X'hh' sequences)
  • one can edit multiple files in the same session
  • one can split the screen horizontally or vertically to view different files or different sections of the same file

  • one could write entirely new editing commands as procedures (macros, scripts) using exactly the same scripting language one used for the equivalent of "shell scripts" under VM/CMS (I originally used EXEC and later EXEC2, while I never learned to do it in rexx which was latest IBM choice.
  • in fact lots of IBM system utilities were actually just wrappers around collections of XEDIT macros and configurations (with specific commands, PF-key settings and screen layout). This included :
    • the original NOTE e-mail command, and the SENDFILE interface to the spool area used to exchange files among computers.
    • the FLIST and FILELIST terminal-oriented file managers which are still better than any window-oriented file managers I've seen.
    • the later MAIL and MAILBOOK utilities.

  Just for these reasons for instance I went on reading my mail on an IBM via a tn3270 emulator long after I had first a VAX terminal and later an Unix workstation on my desk, and doing some peculiar edits ftp'ing my files back and forth to the IBM mainframe. I ceased only when this was gone.

• I did not do much use of VAX EDT, which was not unlike its PDP predecessor. Essentially it was once again a combination of a line-mode and full screen editor.
  One was normally in line-mode (where one could issue usual mnemonic commands) and entered the full screen (change) mode with the Change command. (to avoid clashes the string change command was Replace - or was it Substitute?)
  In full screen mode one was (annoyingly) always in insert mode, and also I was annoyed by the fact that the VAX DELETE key deleted "the other way round". Lots of operations were done using the numeric keypad, usually prefixing one of the numeric keys with the "gold" (PF2) key (VT terminal keyboard had just 4 PF keys on top of the standard numeric keypad). Unfortunately there was no mnemonic display of the usage of the keys constantly present on the screen (one could recall it separately), and I never learned but the few I used.
  On the other hand one could freely scroll the full screen back and forward in an unlimited way (no more "screens" or "buffers")

• I did instead made some use of VAX EVE (TPU). I never mastered the full capabilities of TPU (which should allow one to write one's own editing commands), but settled on a combination of EVE with a partly customised EDT-like keypad (customization via initialization files was quite handy).
  One advantage of EVE was that one was always in full screen mode. The screen had a status line, and an optional command line could appear to issue any of the English verb commands (including the HELP to find rarely used ones, or to display the PF key map).
  EVE screens could alternate between overstrike and insert mode.
  EVE (as EDT) had a PF-key controlled cut-and-paste mechanism.
  This was quite practical with EVE to exchange pieces of text among files, since EVE allowed to edit multiple files in the same session (switching among them via a menu screen).

  I do remember little of EVE nowadays, but I spent quite some time to configure my Unix keyboards to emulate the VT keyboards (and also to configure both to emulate IBM 3270 keyboards), and for a time used EVE as my primary ... Unix editor (that was when I had a VT340 terminal attached to a VAX on my desk, I preferred to edit Unix files accessed via NFS thru the VAX, with EVE, instead of telneting to the Sun and using vi !)

• More or less at the same (late) time we got a VAX (may be a bit earlier), we got also some primitive CP-M PCs. At this time I abandoned using of IBM VS-Script (DCF) (with XEDIT as editor) as text processor in favour of Wordstar.
  I used it for the composition of some manuals, and occasionally also for code writing (since I had such PC as terminal emulator on my desk, while the 3270's were in the user room), hence as an editor.
  I do not have a bad recall of it, it was a decent full screen editor, good for typing text (and also reasonably good as nearly-WYSIWYG text processor, but that is a different story) : in fact I note that my editing requirements for text and program code are different, and I do less use of "editing commands", like arbitrary replacements, and scripting, when composing text w.r.t. to editing code or data.
  It had a way to issue commands via control sequences, usually double as control-K-B or control-P-F (where the first letter was common to a "class" of commands) : I do not particularly like this way, but I could go along with it because some sequences were mnemonic and because a reminder menu of the current class of commands was present on the screen (at the expense of wasting a few lines).

• I did little use of "standard" PCs, line editors like edlin were no longer acceptable. At the time I had to do some programming on a PC I did use some sort of KEDIT which was not so unlike a descoped version of XEDIT, but this lasted only a short time.

• to conclude the digression about PCs and word processor, I do use MS Word for documentation (originally on a Mac, and now mainly on a "remote" Win NT machine). As said, word processors are a different story, as an editor for document text Word is generally acceptable, although things like scripts with automatic replacement of patterns are usually not easy.
• in the rare case I need to edit plain files or code on a PC I'd use notepad or the imbedded editor in the programming (VB) environment. Or I edit plain files on Unix, since my Unix disks are SAMBA-accessible.

• As soon as we moved to Unix, we encountered the usual problems : of course nobody nowadays can seriously consider a line-editor like ed, so the choice was with the dreadful vi.
  That (or at least the termcap concept behind it) could have been a modern approach to portable screen editors when it was designed, but as far as handiness is concerned, vi is horrible :
  • it is terribly confusing the fact that all editing commands (including in principle basic things like arrow keys) are associated with normal keyboard letters, and that, therefore, typing an a, and r or a d "on the screen" results in some command being executed instead of some text typed in the file.
  • particularly annoying is then the fact that one must use the escape key to exit from a mode like insert or append (which one may not remember one is in, if one comes back to the terminal after a while).
  • also the majority of commands are not mnemonic at all, and anyhow are (as most things in Unix) exceedingly "terse"
  • I also never managed to get fully along with regular expressions (although I liked the ones of EDIT/1000)
  • this is particularly true for the use with sed at shell level, where some characters conflict with shell usages and require escaping. I find rather poor and disappointing the need to use a different editor like sed instead of an editor with imbedded scripting capabilities (and in such cases I'll either do the job in awk or use a XEDIT clone).

  Therefore I learned only the few commands (i, a, r, x, dd, /, :q and :wq needed to use vi when I'm compelled to (as root or in single user mode), and use other editors.

  I also never used any variety of emacs (I do not know LISP), also for the good reason we never had it installed with the system, and for the fact I do not like "control-X control-W" type editors (I do prefer English verbs).
  Therefore I'm not a partaker of the eternal vi vs emacs flame war

• My first choice (or forced choice) on Unix was Sun's textedit. I did use it (or its subsequent variants under SunOS SunWindows, SunOS with X11 OpenLook and Solaris) only occasionally, because I do not have a Sun workstation on my desk.
  I do not know therefore whether the critics I can make are to the editor itself, or to arrangement specific of the look-and-feel of the Sun windowing environment : I find the access to menus is somewhat clumsy, there too many or different mouse buttons to press, and that mouse-oriented cut-and-paste via the dedicated copy, cut and paste keys is annoying.

• My current prime choice is dxnotepad, which I've used since I had an Ultrix station on my desk, and I'm using now on an Alpha with DU 3.2.
  The general performance is the same of any basic, window-and-mouse oriented editor. Things which I like (or prefer to the equivalent functions in textedit) are :
  • the use of some accelerator sequences (the ones I use, the other ones I ignore), which are either sufficiently mnemonic or similar to the ones used in MS-Word (for instance the control-X control-C control-V for cut, copy and paste)
  • the fact I can normally use the quick copy mouse facility (which means one mouse button is used for almost everything, and the second one just for copy)
  • the search Next.. and Previous.. and Replace Once, Replace with Selected Area and Replace All menu facilities, which provide a decent choice
  • the navigation options (Top and Bottom) and the split-screen facility, very useful in editing both code and text to compare two areas of the file
  • the possibility of changing font from the inside (useful when I must show my work to visitors and toggle from my usual tiny fonts to a big bold Courier clearly visible from afar)
  • the possibility of customising X-resources, like the background colour (this is something we systematically do also for textedit, i.e. we provide a few edit, edit1, edit2 ... aliases each one with a different background colour, so that one can tell at a glance which file is editing looking at its colour)

• These are possibilities I will sorely miss if I'll be forced to make the move to dtpad (under CDE) which looks rather more primitive (and anyhow I'd use its StandAlone mode in order to access X resources).

• I do occasional use of XEDIT clones under Unix.
  Our first choice (which we installed both on Sun and DEC workstations) was for xc. Although its level of support appears frozen, it provided most, although not all, of the basic capabilities of XEDIT (but no scripting capabilities).
  I do use it sometimes for hex editing, column editing or views-by-pattern (ALL command), or when telneting from outside.

  A second, and most likely the future choice is THE Hessling Editor. This is actively supported by the author and by a group of macro contributors, should emulate XEDIT almost in full, and has scripting capabilities (although these require a rexx clone, no EXEC2 clone unfortunately).
  Its earlier versions had limitations, and I occasionally had sometimes some compilation problems under my old DU 3.2 (I hope they'd disappear on a more modern OS version).
  Anyhow I've elected THE 3.0 as my future editor of choice, and spent some time in configuring it to my tastes.

• The other editor I use is pico. I use it mainly as mail composer inside my favourite mail agent pine. Only very occasionally I use it as standalone editor (or as the pilot file manager) when telneting from outside.
  It's a very basic editor, but very suitable to write mails (particularly because of the wrapping-and-justifying facility). If I need to do extensive changes to a long message, maybe included from other files, I do switch to dxnotepad as pine's alternated editor.
  Nevertheless I can go along with its (few) control-sequence commands, because most commands are rather mnemonic, and there is a 2-line reminder menu of commands on the bottom of the screen.