SOF1'WARE~-PHAC'I'ICE A h D E XP E RIE hCE , V O L .

10, -57-76 (1980)

Development of the ZED Text Editor

PHILIP HAZEL
Computer Laboratory, Corn Exchange Street, University of Cambridge, England

SUMMARY
The development process which resulted in a new text editor is described. The reasons for
undertaking this development are discussed, and in particular the increased amount of non-
interactive use of text editors is stressed. The approach taken to the project is described,
including the involvement of users in defining the specificationand testing prototypes. Finally
the main features of the new editor, ZED, are covered.
KEY WORDS Text editor T e x t processing OS/360 E D I T

INTRODUCTION
T h e IBM 370/165 at Cambridge provides batch and timesharing services for academic
users. Early in the life of this machine a general-purpose text editor was developed
which would run in both the timesharing and batch environments. This program is
called E D I T . ' Its facilities are based on a previous text editor developed in Cambridge
for the Titan computer.2
From the time that E D I T was put into service, users continued to suggest extensions
and enhancements. Some of these were included in the program, but after a time
modification became more and more difficult as the original design was stretched to its
limit. Certain inadequacies were impossible to correct, and finally a major redesign was
undertaken. T h e result was a completely new text editor, called ZED.
T h e following sections describe some of the inadequacies of E D I T , and why it was
not possible to overcome them without a major redesign, the considerations involved in
the design of ZED, the implementation and testing process, and ZED itself.

INADEQUACIES OF E D I T
E D I T was conceived as an interactive editor, with non-interactive use a lesser activity,
mainly required for simple tasks such as incremental editing. However, more and more
users began making use of E D I T as a general text manipulation language by means of
stored sequences of commands which were run on a regular basis. One example of such
use is the maintenance of a list of members of a society, together with associated
information such as type of membership, address, telephone number, etc. Provided the
various fields are delimited by appropriate character strings, E D I T can be used to
extract subsets of this data, such as all the members in a given town. Another common
use is the post-processing of output from other programs.
Using a text editor in this way may not always be the most efficientsolution to the
problem in terms of machine resources; however, it is very efficient in human resources
because the user is working within a familar system where all the data is immediately
0038-0644/80/0110-0057$01 .OO Received 20 July 1979
@ 1980 by John Wiley & Sons, Ltd. Revised 21 September 1979
57
58 P H I L I P HAZEL

readable and debugging can be carried out interactively. These are the same benefits
that can be obtained by using an interactive programming language such as APL for
computational problems. A text editor can also be used to implement quick
experimental versions of text processing algorithms before investing resources in full
scale implementations.
While it is possible to do the sort of processing described above using E D I T , in many
cases the command sequences are very clumsy. There are three main areas in which
E D I T facilities are lacking: searching, command control and line handling.

Searching
In E D I T , the only facilities for searching for a particular line of text are the F and L
commands, which search for a line beginning with or containing a given string,
respectively. T h e ability to find a line N O T containing a given string, or containing any
one of a number of strings, and the ability to find empty lines were the most often
requested extensions.

Command control
E D I T contains no explicit control commands. LJsers wanting to test for the presence
of a string in a line have to do a dummy alteration to the line, and ignore the resulting
error when the string is not present. This is unsafe as well as clumsy. Explicit control
commands such as IF and W H I L E were frequently suggested.
T h e restriction that a repeated group of E D I T commands must be all on one line
(originally imposed for efficiency reasons) diminished the usefulness of this feature.

Line handling
E D I T deals with one line of source text at a time and always moves forwards through
a source file. T h e restriction to forward movement was imposed for efficiency and to
minimize the amount of store used. In practice many operations require two passes
through the file because of this restriction, thus nullifying any efficiency gains.
Consequently an enhancement that allowed cheap backward movement was desirable.
A related facility is the movement of a line or lines from one part of a file to another.
In E D I T this must be done by writing out the lines to be moved to a disc file and then
reading them back again which is a comparatively expensive operation.

UPGRADING CONSIDERATIONS
This section summarizes the reasoning behind the decision to implement a new editor
in the same style as E D I T , and describes how the design was carried out.

Full screen editors

Since E D I T was first implemented, terminals with screen displays have become
commonplace on all types of processor. It is widely agreed that the most humanly
acceptable form of interactive text editing is by means of a full screen editor which
displays a page at a time and allows the user to point, by means of a light pen or cursor,
at the portions of text to be amended. Such an editor requires a device capable of
operating at high speed in page mode.
T h e provision of a full screeen text editor as an upgrade to E D I T was not considered,
for the following reasons:
 ZED TEXT EDITOR 59

1. I t would be purely interactive rather than general purpose; the deficiencies o f

E D I T are felt most in non-interactive applications.
2. There are no full screen devices currently attached to the 370/165, and in any case
such devices are likely to remain in a minority because of cost.

Imported editors
Having decided that a more up-to-date editor was desirable, one approach would
have been to have acquired an existing editor from elsewhere. T h e reasons for not
looking for such an editor were twofold. Firstly, it was very important to preserve as
much compatibility with E D I T as possible. There are currently over 2000 registered
users of the 370/165, many of whom have been using editors in the style of E D I T for
more than a d e ~ a d e . ~
Secondly, the unique problems of running under the OS/360 operating system made
it highly unlikely that software from elsewhere would adhere to local utility standards.
An editor was required which would run sensibly both interactively and in the batch,
and would be capable of reading and writing any sequential file in the system.
T h e last point requires some elaboration for the benefit of readers not familiar with
0 5 / 3 6 0 . Under this operating system sequential files may be in one of three formats:
fixed length records, variable length records or undefined length records. In addition,
the first two types may be blocked or unblocked, and variable length records may,
optionally, span physical blocks. T h e record lengths and block sizes may be chosen
arbitrarily by the user, within the physical limits of the peripheral device. A further
complication is that the first character of the records in any given file may optionally be
designated as a control character, and there are two possible kinds of control character.
At the level of the interface to the operating system, the programmer must be aware
of all the possible formats for sequential files, and must write code to deal with each of
them. Special code is also required for driving terminals in an interactive fashion. A
consequence of this is that many Assembler programs and high level language systems
support only a subset of the available formats. A truly general purpose editor, however,
must be capable of dealing with all of them, and must also be capable of converting
input in one format to output in another.
A further implementation restriction was imposed by the fact that the 370/165 does
not have paging hardware, and hence does not offer virtual memory facilities. T h e
editor therefore has to make minimal demands on main storage, and is required to be
re-entrant in order to reduce the swapping overhead for interactive users.

The design process

T h e first planning document proposing a major upgrade to E D I T attempted as far as
possible to keep a compatible syntax for editing commands. During the discussion
which followed it became clear that it was impossible to provide all the required
enhancements within the old syntax. One of the main problems was that E D I T allows
any character as a delimiter for text strings. T h u s the F command, which finds a line
beginning with a string, could for example be written

FFABCF
in order to find the string ABC. As a result of this delimiter rule only one command can
begin with the letter F. This can, of course, easily (and only slightly incompatibly) be
overcome by forbidding the use of letters as delimiters. There still remain problems
60 PHILIP HAZEL

with special characters if, for example, a way of specifying ‘the last search string’ is
required. T h e use of the space character as a delimiter causes difficulties when strings
are given attributes represented by letters, and these must be separated from the
command name by spaces.
T h e result of the planning discussion was a decision to design a completely new text
editor, retaining compatibility only where convenient. T h e processes of design and
implementation were then carried out in parallel, experience of using the first
primitive, incomplete versions being fed back into the design.
T h e development of the user specification was coordinated by one person. However,
the many drafts that were produced were widely circulated and comments were
received from many sources. T h e implementation was entirely a one-person affair. T h e
elapsed time from start to first general release \vas one year; the estimated time spent on
the program was six months. Very early in the implementation cycle primitive versions
of Z E D were made available to selected users for evaluation. T h e first of these consisted
of little more than the F command. T h e feedback from this experimental use was
invaluable in detecting poor design choices as well as program bugs. A number of
changes were made to the syntax of editing commands, some of them fairly substantial,
and several commands were respecified as a result of user comments. Such modifi-
cations were possible because Z E D was developed in an environment which
encourages flexibility. In addition, as it was a redevelopement of an existing facility,
there was no deadline for its completion. T h e result of this parallel design and
implementation is a program whose rougher edges had been removed before release to
the general user population.

M A I N F E A T U R E S OF Z E D
This section describes the most important facilities provided by ZED in an informal
manner. A complete list of editing commands (including many not described in this
paper) is given as an appendix, while a full specification of the program appears in
Reference 3 .
Z E D commands consist o f a command name, which is either a sequence of letters or a
single special character, optionally followed by arguments. Seven different types of
argument exist: strings, qualified strings, search expressions, names, numbers, sw-itch
values and command groups. Commands are delimited by end of line (except within
parentheses) or the semicolon character. Spaces may occur between a command name
and the first argument, between non-string arguments, and between commands. A
space is only necessary in these places to separate two successive items kvhich would
otherwise be treated as one (e.g. two numbers). T h e character \ is used to introduce
comment, terminated by end of line.
Many commands may be obeyed a fixed number of times by preceding them by a
count. For example,
3N
obeys the N command (mhich moves to the next line) three times. A sequence of
commands may be grouped together by enclosing it in parentheses. Such command
groups may optionally be preceded by a count, may extend over more than one line of
command input, and may be nested to any depth. Command groups are used as
arguments for the control commands.
 ZED T E X T EDITOR 61

String matching
A string in ZED consists of an arbitrary sequence of characters enclosed in matching
delimiters which do not themselves appear in the string. T h e delimiter character for
any given string must be one of
+ - * / . , ? ! : 0 I 4

Some examples of strings are

/ T h e cat/ :A = A + B(1): “/-it’
In the examples which follow, the solidus character / is used as the string delimiter.
T h e basic unit of string matching in ZED is the qualified string, which is a string
preceded by a sequence of qualifying letters. These place constraints on the matching
process. A string with no qualifiers w i l l match anywhere in a line o f source text, but a
string preceded by B will match only at the beginning of a line. T h u s for example,
F /Jabberwocky/
will find a line containing ‘Jabberwocky’, but
F B/slithy toves/
will only find a line which begins with ‘slithy toves’. Similarly, a string preceded by E
will only match at the end of a line, while a string preceded by P will only match a line
containingprecisely the given characters and nothing else. If P is used with a null string
it matches an empty line.
T h e qualifier N can be used in conjunction with other qualifiers, and it negates the
result of the matching test, T h u s
F NB/The sun was shining/
finds a line that does not begin with ‘The sun was shining’. Note that this is not the same
as a line containing ‘The sun was shining’ not at the beginning.
F NP//
finds a non-empty line. T h e qualifier W specifies a word search, which means that the
string that is matched must neither be preceded nor followed by a letter or a digit, while
the qualifier U specifies that the matching is to take place as though all the letters
involved were uppercased. T h u s
F UW/king,’
will find lines containing the words ‘king’, ‘KING’or even ‘KiNg’, but not ‘kingpin’ or
‘thinking’.
T h e qualifier S specifies that lines are to be considered as starting at the first
significant (non-space)character. This is most often used in conjunction with the B or P
qualifiers when editing indented text. For example,
F SB/X: = /

If a string occurs more than once in a line, the second or subsequent occurrences can be
matched by specifying a numerical qualifier. For example,
2IcatI
62 P H I L I P HAZEL

matches the second occurrence of ‘cat’ in a line, and hence

F 2/cat/
finds a line containing at least two occurrences of the string ‘cat’.
A matching operation can be restricted to certain character postions in a line by
means of the column qualifier.
F [73,80]/ABCD/
searches for a line containing ‘ABCD’ in columns 73-80.
As Lvell as their use in the F command, as illustrated in the above examples, qualified
strings are also used to indicate a position in the current line at which textual changes
are to be made. In these cases the N qualifier is not allowed. For example,
B UW/king/Red/
causes the text ‘Red’ to be inserted before that point in the current line matched by
UW/king/. T h e beginning and the end of the line can be indicated by the qualified
strings
li and E//
respectively. There is also a qualifier L which causes the search for the string to occur
leftwards, thus ensuring that the last occurrence in the line is matched. If the current
line were
If seL’en maids with sel’en mops
then the command
B L / seven / twenty - /
would turn it into
If seven maids with twenty-seven mops
A numerical qualifier can be used with L to match the nth last occurrence of a string.
Other commands for operating on the current line are A (insert string after), E
(exchange string), DFA, D F B (delete from after, before), D T A , D T B (delete till after,
before), LC, UC (force lower, upper case) and SA, SB (split line after, before).
Whenever a current line is first altered by means of one of the above commands, a
copy of the original line is taken. At any time before the line ceases to be current the
original line can be restored by means of the U N D O command. This provides a
convenient means of recovery from typing errors when editing interactively.

Search expressions
I
Qualified strings may be combined using the operators & (logical and) and (logical
or) to form search expressions. Search expressions are always enclosed in parentheses,
may contain nested parentheses, and may extend over more than one line of command
input. They are used as arguments to commands which search for or test lines of the
source. Commands which perform some action on the current line are restricted to a
single qualified string argument, as described in the previous section.
T h e command
F (/SUBROUTINE/ I / F U N CT I O N / )
 ZED TEXT EDITOR 63

finds a line containing ‘ S U B R O U T I N E ’ or ‘ F U N C T I O N ’ (or both), whereas

F (B/king/ & (NE/queen/ 1 /knave/))
finds a line beginning with ‘king’ and not ending with ‘queen’ or beginning with ‘king’
and containing ‘knave’.
T h e only restriction on the size and complexity of search expressions is the amount of
main store available to ZED.

The last search expression

T h e last obeyed search expression is re-accessed in a subsequent command if & is
written for the argument. For example,
F /Tweedledurn/; N ; F &
finds a line containing ‘Tweedledum’, moves to the next line, then obeys the second F
command using the same argument as the first. Commands such as F which take only a
single search expression argument can in fact be written without arguments, in which
case & is assumed.
T h e N command used in the above example is necessary because F always starts its
search at the current line. It was recognized during the design of Z E D that this is not an
ideal specification for an interactive editor, where the user I s unlikely to type redundant
F commands. However, in non-interactive applications, particularly in cases where
files of editing commands are stored and updated, the required line may already be
current at the start of an F command as the result of some previous, unrelated editing
operation, and should therefore be included in the search.
In addition to its use with the F command, & can be used for commands which
operate on the current line and which require a qualified string argument. For example,
F /Tweedledurn/; E&/Tweedledee/
finds a line containing ‘Tweedledurn’ and then obeys
E/Tweedledum/Tweedledee/
to exchange the two strings. This use of & is only valid when the most recently obeyed
search expression succeeded, and in succeeding defined a unique position in the line.
Thus
F (/red/ 1 /white/); E&/purple/
is a valid use of &, because whichever string is found will define the point of exchange.
However,
F (/red/ & /white/); E&/purple/
is invalid, as is
F N/red/; E&/purple/

Control commands and loops

ZED contains a flexible set of control and loop commands, which include IF, U L
(unless), W H (while), U T (until), I F E O F (if end of file), U L E O F (unless end of file)
64 PHILIP HAZEL

and U T E O F (until end of file). T h e first four apply a search expression to the current
line to test which control path to follow. For example,
I
I F (/cat/ /dog/) T H E N (
B[73,80]//animal/; ? ) E L S E D
tests the current line for one of the strings ‘cat’ or ‘dog’. If either is found the string
‘animal’ is inserted in columns 73-80 and the line is verified ( ? command); if neither is
found the E L S E branch is taken and the current line is deleted.
A series of tests on the same line may be written using the connectors E L I F (else if)
and/or E L U L (else unless). This reduces the number of parentheses required and
makes the commands easier to read.
T h e loop commands repeatedly obey their command group argument while or until
the search expression matches the current line. T h e scan for the elements of the search
expression starts at the beginning of the line for each iteration. There are, however,
windowing commands for setting a logical line beginning, and these may be used within
the iterative command group to skip over contexts already dealt with. A simple example
of the use of a loop command is
WH/ /E&//
which has the effect of changing all multiple spaces in the current line to a single space.
U T E O F (until end of file) is special in that it exits from the loop when an end of file
error message would otherwise occur. T h u s it can be used in sequences such as
UTEOF (F/unicorn/; B//***/; N )
which will eventually complete when the F command fails at end of file.
T h e normal flow of control in loops can be broken by means of the AGP (abandon
group) command. This has the effect of exiting from the nearest textually surrounding
level of command group parentheses, and any command of which the group is an
argument. For example,
W H B/*/ (A/*/ /; N; I F E O F AGP)
inserts a space after the initial * of successive lines until either a line not beginning with
* or the end of the source is reached. A repeat count can be used with AGP to exit from
more than one level.
Movement through the source
T h e N command, which moves to the next line of the source text, has appeared in
several previous examples. There is also a command P which moves back to the
previous line. Similarly, corresponding to the F (find) command, which moves
forwards, there is a B F (backward find) command which performs the same operation
moving backwards through the source.
ZED implements backwards motion by keeping previous line in main store a s long as
possible before writing them out to the destination file. Backward motion to the start of
the text is therefore not always possible for large sources. This restriction is imposed for
reasons of efficiency. It means that no intermediate disc copies of the text are required
in the majority of editing applications. T h e maximum number of lines held in store at
one time depends only on the store available; on the Cambridge system where about
30K bytes of store is available for interactive use of ZED, around 500 lines can normally
be held.
 ZED TEXT EDITOR 65

A number of other commands are available for traversing the source, either as their
sole function or as a side-effect. Some of these take line numbers as arguments.
Each line that is read from the source is given a unique line number. Such lines are
initially in ascending sequence of line number and are termed original lines. New
inserted lines do not have line numbers, and lines which are moved around in the
sequence (see the section Line shufling) become non-original, and can no longer be
referenced by line number. Hence commands with line number arguments can always
determine from the argument in which direction to move.

Line shuffling
ZED provides 16 in-store buffers for the purpose of moving blocks of text around,
and for replication. T h e T O command is used to specify the destination for lines which
are passed in a forward direction. T h e default destination is a queue which is emptied
onto the output file when its store is required, and at the end of editing.
TO BUFF n
directs lines to buffer n instead of the default queue;

TO

reverts to the default. T h e contents of any buffer other than that to which lines are
currently directed may be inserted into the text before line m b y the command
Im BUFF n
If m is omitted, the insertion occurs before the current line. A copy of the contents of a
buffer can be inserted by the command
Im COPY n

This feature enables easy replication of blocks of text. T h e following example moves
lines 10-1 5 to immediately before line 36:

M10 \move to line 10

T O BUFF 3 \select buffer 3
M16 \output lines 10-15
TO \revert to normal output
I36 B U F F 3 \insert buffer 3 before line 36

This technique can also be used to move text to an earlier part of the source, provided
that the insertion point is still in store and can be accessed by moving backwards.
T h e system of input and output queues and in-store buffers may be visualized as a
railway shunting yard where the T O command operates the points, and each bvagon
represents a line of text. This is depicted in Figure 1.
At the end of each siding representing an in-store buffer there is a tunnel which
connects through to the insert siding and which is brought into use by the I command
with a buffer argument. When COPY is used with I this tunnel generates a copy of the
lines in the buffer instead of moving the lines themselves.
T h e lines in a buffer can also be processed one by one as current lines by selecting the
buffer as a source using the F R O M command.
66 P H I L I P HAZEL

[main store]

***Current Line***

FROM BUFF n
has the effect (in railway terms) of connecting a tunnel from the end of the siding for
buffer n through to a point just before the current line. Commands which move
fonvards through the source then access the lines in the bufier. A dummy end of file is
generated Lvhen the buffer is empty, and the command
FROM
may be used to revert to the normal source file.

Input and output selection

As well as controlling the in-store buffers, the F R O M and T O commands can be
used to select different input and output files. In this case the argument is a string which
is an operating system dependent file name. For example,
 ZED T E X T EDITOR 67
FROM / D D l /
In the case of the T O command the queue of output lines is Lvritten to the output file
before the switch is made, and for both commands the old file is left open so that
reselection can take place later. These facilities can be used to merge a number of
different sources, to split u p a file into a number of separate files, or to effect line
shuffling when the quantity of text to be moved is too great to fit into an in-store buffer.
For example,

M 1000 \ move to line IOOO

TO /DDl/ \output to temporary file
M1501 \lines 1000-1500 queued for DD1
TO \ reselect normal output
C F /DDl/ \close file DDl
13600 / D D l / \insert before line 3600

Space compression
A frequent use of a text editor is for the removal of redundant spaces from text, for
example when inspecting data intended for a line printer at a slow and/or narrolv
terminal. This can be done in ZED by means of the O N command (see the section
Global operations) but because it is so common a special efficient facility is provided.
T h e command
cs +
turns on space compression, which ensures that all leading and trailing spaces are
removed, and all multiple spaces converted to a single space as source lines are read.
T h e command
cs -
turns compression off.

Justification
E D I T contains facilities for very simple justification by ensuring that all lines
contain the maximum possible number of words. Similar facilities are provided in
Z E D , but instead of action taking place immediately the reIevant command is obeyed,
the justification parameters are remembered and used whenever a current line is passed
in a forward direction or a line is inserted. T h u s justification takes place in parallel with
other editing activities.
T h e justification commands are as follows:
JLn
Set justification line length to n. Justified lines will not be longer than n characters.
J + J-
Enable/disable justification. T h e default state is with justification turned off. As in
E D I T , indented lines, blank lines and overprinting lines are taken as the start of new
68 PHILIP HAZEL

paragraphs. A sequence of indented lines can, however, be justified by using the

command
RJn m
which restricts justification to columns n to m. Any lines which contain text outside
these columns are not justified.

Global operations
Z E D provides the ability to specify global operations on the source text which are
carried out in parallel with other editing. T h e single global command of E D I T has been
replaced by the three commands GA, G B and GE which act globally in the same way
that the A, B and E commands act on a single line. Thus, for example,
GA/cat/fish/
changes every occurrence of ‘cat’ into ‘catfish’ in the current line and in all succeeding
lines until the end of the source is reached or until the global command is cancelled or
disabled. T h e command
GE/cat/catfish/
is equivalent. All the features of qualified strings are available in these commands:
G A UW[60,]/the/y/

changes all occurrences of the word ‘the’, in upper or lower case, following column 60,
by adding the letter ‘y’.
T h e facility provided by the G commands is adequate for global changes involving
simple additions or exchanges. More complicated operations can be specified by means
of the O N command, which takes as its arguments a search expression and a command
group. Whenever a line that matches the search expression becomes current during
forward motion, the command group is obeyed. Commands in the group are restricted
to those that do not move to a different current line. For example
I
O N (BS/SUBROUTINE/ B S / F U N C T I O N / ) (I
c
c
Z
COMMENT /NEW ROUTINE1
3

1
causes two empty F O R T R A N comment lines to be inserted before any statement
beginning with S U B R O U T I N E or F U N C T I O N , outputs a comment to the
verification file, and verifies the line. T h e command
O N B/*/ (WH/**/ E&i*/)
causes all multiple asterisks to be changed to a single asterisk in lines which begin with
an asterisk. An ON command may also optionally specify an E L S E command group,
kvhich is obeyed whenever the search expression does not match a new current line.
Each global command, whether G type or ON type, is allocated a number when it is
obeyed. This number can be used as an argument to the DG, EG and CG commands
 ZED TEXT EDITOR 69

which respectively disable, enable and cancel the relevant global operation. Omission
of an argument causes all existing globals to be affected. For example, to apply a global
exchange to lines 13-19 and all lines after the one containing precisely (0) the
following commands could be used:
M13 \move to line 13
GE/cat/dog/ \set u p global exchange
M19 \,move to line 19
DG1 \disable global 1
ON Pi(())/ EG1 \enable when (0) encountered
T h e currently existing globals can be inspected by means of the SHG (show globals)
command. As well as listing the global numbers and corresponding commands, the
number of times that each global has matched is given.
Procedures and command files
Z E D procedures provides a means of naming sequences of commands for later use.
There are no facilities for providing arguments to procedures. T h e command
PKOC SQ (WH/**/ E/**/*/)
sets u p a procedure called SQ, which, when obeyed by
DO sy
squashes the current line by removing multiple asterisks. Procedures may be called
(though not defined) within other procedures, and may be called recursively. T h e
SHPKOC and CPROC commands are used to show and cancel procedures
respectively.
A sequence of Z E D commands may be read from a file other than the current
command file by the command
C /filename/
T h e argument is an operating system dependent file name. When the file is exhausted,
control reverts to the previous command file. T h e C command can also be used to read
command lines from an in-store buffer by using one of the forms
C BUFF n
C COPY n
?'he former leaves the buffer empty while the latter leaves it intact. This facility means
that a sequence of ZED commands is capable of building u p further sequences of
cotnmands whose content is dependent on the source text being processed.
Non-Printing Characters
A source text that is being edited may contain characters that are not available on the
terminal or other device that is being used for verification output. Z E D provides a
special Verification command intended to be used on lines containing a small number of
such characters. Whereas the normal verification command ? outputs the current line as
it stands, the special verification command ! generates two lines of output. T h e first line
is the current line with special characters replaced in one of two ways:
1. Special characters which can be input using the standard escape mechanism on
the Cambridge communications system are replaced by the escape character @.
70 P H I L I P HAZEL

2. Other special characters are replaced by the first hexadecimal digit of their
EBCDIC value.
T h e second line of output contains hyphens under upper case letters, the rest of the
escape combination under any escape characters, the second hexadecimal digits of any
other special characters, and spaces in all other positions. Typical verification output
from the ! command might be
T h e King bought @ [email protected]
- -
@5$
1 he escape combinations @ @ and @ $4 represent an @ and a A character respectively,
r ,

:vhile the hexadecimal 05 is a tab character.

For editing binary data or data with a high proportion of non-printing characters,
+
Z E D can operate in hexadecimal mode. This is switched on and off by the X and X -
commands. In this mode lines are verified in hexadecimal as a series of eight character
groups, and command strings referring to textual data must also be expressed in
hexadecimal. T h e line used in the above example would be verified as
E3888540 D2899587 408296A4 8788A340 7C054AF1 F44BF5FO
and to change ‘The’ to ‘Their’ the command
A/ 8 5 188 891
could be used.
Commands copied from EDIT
A number of E D I T ’ S commands are reproduced without any essential change in
ZED. These include the line number oriented insert, replace and delete commands (I,
R and D ) , the commands for operating on individual characters (), # , O 0 , $ ) and the
margin, Lvindow and fixed field commands (MA, MAV, RV, R F and K).’

IMPLEMENTATION
Z E D is kvritten in IBM 370 Assembler, for reasons of size and efficiency. It is, however,
designed in a structured manner as a series of well-defined procedures with a standard
interface convention. This discipline has proved very effective in simplifying the
debugging process. T h e code of Z E D occupies 36K bytes of main storage. A minimum
of 8K bytes of working storage is required; if more is available Z E D uses it for holding
more of the source in main store.
T h e algorithms used in implementing Z E D are mostly straightforward in nature,
with one exception. T h e algorithm used for searching for a given string in a line of text
is a modified version of that published by Boyer and Moore.4 Their algorithm involves
the use of a table of 256 bytes (for EBCDIC code); in the context of Z E D this is too great
an overhead both in terms of store and in terms of set up time for very short string
searches. Instead a table of length 256 bits (32 bytes) is set up for each qualified string
when it is decoded. This table indicates the presence or absence of each character in the
string, and is used to implement the first feature of the Boyer and Moore algorithm. A
useful byproduct is that some of the cost of searching for an alphabetic string in either
upper or lower case can be avoided.
T h e code of Z E D includes a store manager which works on a first fit basis, with
amalgamation of contiguous free blocks. T h e range of sizes of block is relatively
 ZED TEXT EDITOR 71

restricted, and most blocks are small. Fragmentation problems can occur however
during operations which involve opening and closing files with large blocksizes. Such
operations are fortunately rare.
A stack is used to implement the procedure calling conventions, thus naturally
providing facilities for recursion which are exploited when processing nested command
groups.
Z E D decodes and translates each line of commands into an internal data structure
before starting to obey the line. T h i s is in contrast to E D I T , tvhich obeys commands
interpretively from the textual form. Syntax errors in ZED are detected before any
commands on the line have been obeyed, thus limiting the effects of typing errors more
strictly.
Over 80 different error messages may be issued by ZED. These range from simple
warnings about fixed field overflows to serious errors such as insufficient store. T h e
interactive user is always given the opportunity to enter more commands following an
error except after internal consistency failures (which should never occur).

c0NC:I, u sI 0 hT
This paper has described the design and implementation process which took place as a
result of the decision to produce a new text editor, and has also covered the major
features of the resulting program. T h e iterative nature of the design, coupled with
prototype testing in the user community, has led to an editor which has rapidly gained
wide acceptance. Indeed, the news of the existence of the final prototype versions
spread so rapidly by informal means that comments were received from several dozen
users, many of whom were not personally known to the author.
T h e main feature which distinguishes Z E D is its attention to the needs of the non-
interactive user. Facilities to enhance programmability have been provided in such a
way that the interactive user is not unduly penalized.

ACKNOWLEDGEMENTS

Many staff and users of the University Computing Service contributed ideas and
suggestions for the improvement of E D I T , which eventually spurred me into
undertaking the implementation of ZED. Many more took part in the exercise of
designing the new specification and trying out the prototypes. My thanks are due to all
those who gave their time and effort, in particular to Arthur Norman who invented
qualified strings and persuaded me that they were a good thing, and to Brian Kelk who,
as well as making many suggestions about the specification, found more bugs in the
prototypes than anyone else. T h e comments of an anonymous referee have enabled me
to make a number of improvements in the text of this paper.

APPENDIX-ZED COMMANDS
Argument abbreviations:
a, b line numbers (or . or *)
cg command group
m, n numbers
q qualifier list (possibly empty)
72 P H l L I P HAZEL

se search expression
s, t strings of arbitrary characters
SW switch value ( + or - )
name sequence of letters (4 significant)
Qualifiers:
B beginning
E ending
c control character
L last
P precisely
w word
U upper case
S significant
N not
n count
[n ,In1 window
Line selection
Ma move to line a
lvl * move to end-of-file
M- move back as far as possible
M+ move forward to high water
N move to next line
P move to previous line
F se find (forward)
B F se backward find

Line insertion and deletion

Insert material may be any one of
(in-line text, any number of lines
terminated by 2 on its own line)
BUFF n to insert an in-store buffer
COPY n to insert a copy of an in-store buffer
Is/ to insert the file with ddname or dsname s

Ia insert before line a

Ra b replace lines a to b
Da b delete lines a to b
DF se delete find
DRES'I' delete rest of source
DBUFFn delete contents of buffer n
DBUFF delete contents of all buffers

Line windowing
KFn m restrict find
KVn m restrict view
) move character pointer to right
 ZED TEXT EDITOR 73

( move character pointer to left

PR reset pointer to start
PA sisl point after
PB slsl point before
EWR end window right
EWL end window left
EWA slsl end window after
EWB slsl end window before

Single character operations

force lower case
force upper case
change character to space
delete character

after
after and point
before
before and point
exchange
exchange and point
delete from after
delete from before
delete till after
delete till before
force lower case
force upper case
repeat last string operation
UNDO undo current line
SHC slsl show column
CC Is/ set control character

Splitting and joining

SA slsl split after
SB slsl split before
CL Is1 concatenate

Text inspection
Tn type n lines
TLn ditto, with line numbers
T+ type to high water
TL + ditto, with line numbers
TBUFFn type buffer n

File and buffer control

t' Is1 commands from s
C BUFF n commands from buffer n (destructive)
74 PHILIP HAZEL

C COPY n commands from buffer n

FROM BUFF n select buffer n as source
TO BUFF n select buffer n for output
TBUFFn type contents of buffer n
DBUFFn delete contents of buffer n
DBUFF delete contents of all buffers
SHBUFF show non-empty buffer numbers
TO 14 select dsname or ddname
TO select T O
FROM i s / select dsname or ddname
FROM select FROM
CF close all (closeable) files
CF I s / close file with ddname s

Conditionals and loops

Wherever ELSE may appear, the forms
E L I F se T H E N cg ELSE cg
E L U L se T H E N cg ELSE cg
may also appear.

IF se T H E N cg ELSE cg
U L se THEN cg ELSE cg

I F E O F cg ELSE cg if end-of-file
U L E O F c g ELSE cg
~
unless end-of-file
W H se cg while
U T se cg until
U T E O F cg until end-of-file
R P T cg repeat indefinitely
AGP abandon group

Margins
MAn m source margins
MAVn m verification margins

Fixed format fields

M F n l n2 ... mark fields
K n l n2 ... temporarily suspend fields

Jusification
JLn set justification length
J sw enableidisable justification
RJn m restrict justification
VJ sw justification verification

Global operations
C E qlsitl global exchange
 ZED TEXT EDITOR 75

GA qlsltl global after

GB slsltl global before
ON se cg ELSE cg complicated global
CGn cancel global n
DGn disable global n
EGn enable global n
SHGn show global n
VG sw global change verification

State display
SHD show data
SHF show files
SHG show globals
SHS show switches

Termination
w windup
Q quit (exit command level)
STOP sic (return code 8)

Line verification
v sw automatic verification
VJ sw justification verification
V G sw global change verification
VN sw verify line numbers
V T sw verify line texts
VWR sw verify right window
VWL sw verify left window
vw sw verify both windows
VE sw verify edit lines
! verify with character indications
r' verify current line

Procedures
PROC name cg define
SHPROC name show
CPROC name cancel
DO name obey

Hexadecimal mode
x sw switch hexadecimal mode onloff

Miscellaneous
z Is/ set terminator string
T R sw trailing spaces
SQ sw sequence numbers in output
SQS sw source sequence numbers
Ha halt at line a
76 PHILIP HAZEL

COMM is/ comment to verification file

COLS
COLS n
COLS
cs sw
=n
+ I verify column numbers

compress spaces
set line number
BRK sw enable/disable BREAK
REWIND sic
MXLLn max line length
SCC sw suppress control characters
so sw suppress overflow errors
FLUSH flush output queue
STACK n set stack size to n bytes
MXSS n set maximum store size to n bytes
STORE show store usage
MS sw monitor store usage

REFERENCES
1. P. Hazel, ‘A general purpose text editor for OS/360’, Sqftware-Practice and Experience, 4, 389-399
(1974).
2 . S. R. Bourne, ‘A design for a text editor’, Software-Practice and Experience, 1, 73-82 (1971).
3. Cambridge 370/165 Users’ Reference M a n u a l , 4th edn. University of Cambridge Computing Service
(1979).
4. R. S. Boyer and J . S. Moore. ‘A fast string searching algorithm’, C o m m . AC’M, 20, 762-772 (1977).
5 . P. Hazel, ‘The development of text editing at Cambridge’, IUCC Bulletin, 1, No. 3 , Inter-University
Committee on Computing (1979).