MSU EDITOR was a locally-written text editor that was used for nearly all interactive entry of data and program source code. Though not particularly powerful even by the standards of the day, MSU EDITOR was popular because it was fairly easy to use and surprisingly efficient.
MSU EDITOR (which we'll call "Editor") worked differently than most text editors. It operated only on files in proprietary "Editor workfile" format. These files were called EWFILEs because that was their default local filename. No other programs had the ability to read these files, so when you wanted to actually use the text you had entered, you had to copy it to a normal text file via the SAVE command (or "directive").
EWFILEs were indexed sequential files consisting of lines up to 140 characters in length. Each line had a fixed line number, though those numbers could be changed via the RESEQ directive. By default, the SAVE directive appended the line number to the end of each line. For FORTRAN source code, for instance, the line numbers (or "sequence numbers") were placed on the line starting at column 73. This allowed you to easily find a given line of code in the EWFILE given a printed listing. Line numbers looked like floating point numbers, with up to 6 digits before and after the decimal point. It was typical to use only the integer part, and to increment line numbers by 10. When you needed to insert a bunch of lines in between two existing lines, you could resort to fractional line numbers.
EWFILEs had quite a few user-settable attributes. The LENGTH attribute, for instance, controlled the maximum length of lines and where sequence numbers were placed by the SAVE directive. For FORTRAN source, then, you'd use a LENGTH of 72.
Using Editor consisted of entering Editor directives to enter and
manipulate text, list lines, change settings, and so on. The syntax
of most commands was simply the command name followed by zero or more
parameters separated by spaces or commas. For instance, LIST
100-200
listed lines with sequence numbers 100 through
200. These numbers were not ordinals; line 100 would probably not be
the 100th line in the file. In the special case of
text entry, the syntax was line_number[=]text
; for instance:
420= DO 160 J=1,10Entering a line number that was not followed by text deleted that line, so
500would delete line number 500.
Editor implemented search strings by literal string only--no regular
expressions and, as far as I can remember, no wildcards. For
instance, LIST /FORMAT/
would list all lines containing the string "FORMAT". The output might be:
250=2000 FORMAT(I5) 600=C USE THE CORRECT FORMAT
Search-and-replace used the syntax /searchstring/=/replacement/
[,lineranges]
. For this and other commands, zero or more line
ranges could be specified to restrict the command to a subset of lines in
the file. Line range types included:
line_number
to refer to a single line. E.g., 500.
Certain abbreviations were available; I believe
that *FIRST referred to the first line and *LAST to the last.line_number_1-line_number_2
to refer to a range of lines. E.g.,
2300.5-4450. /searchstring/
to refer to lines containing a certain stringBecause Editor operated only on files in the special EWFILE format, it was necessary to save lines to a normal text files in order for another program to be able to read the text. This was done by the SAVE directive:
SAVE,filename[,linerange][,options]
By default, during a SAVE, line numbers were placed starting after the column specified by the LENGTH attribute. The NS (No Sequence) parameter prevented this.
There were special Editor directives that automated a save-and-compile operation. For instance, the FTN directive did a SAVE and then ran the FORTRAN compiler. This directive was rarely used by advanced programmers, because there was no way to specify compiler directives.
There were special hooks in SCOPE/Hustler to accommodate Editor. These hooks allowed both efficient operation and a reasonable user interface (for the time).
Editor directives could be entered via the system command prompt, as if they were operating system level commands. By contrast, the way other programs worked was that you had to explicitly run the program before you could give it input.
The system control point program MANAGER, which received all text
entered at all terminals, knew the syntax of all Editor directives,
including the special text entry format. When a user entered a
Editor directive at the command prompt, MANAGER recognized this. It
copied the directive to a temporary file associated with the user's
job. This temporary file
had a fixed name, something line ZZZINP. If the command was line_number=text, MANAGER did nothing
further. You could enter many lines of text, and MANAGER would
append them to the temporary file very efficiently, without calling
Editor. However, when you entered some other Editor directive, or an
operating system command, MANAGER
would run the control card EDITOR.
Editor would load and execute,
opening the file EWFILE and the temporary file containing
commands. All directives would be read and processed against EWFILE,
which would then be flushed to disk and closed, and the temporary file
would be deleted. Editor would then exit.
On the surface, this implementation seems wasteful. Entering two LIST commands in a row, for instance, caused EDITOR to run twice, each time initializing, reading both EWFILE and the command input file, deleting the temporary file, and exiting.
However, in practice, the design worked efficiently. All I/O was done by custom code; no system-supplied database package was used. Editor was heavily overlayed, so it did not require much memory. The most frequently-used overlays resided in precious ECS memory, so no disk I/O was required to load Editor.
Adding to the efficiency of the implementation was a MANAGER hook for the special disk file TTYTTY. Whenever any interactive command terminated, MANAGER would look for a file named TTYTTY. If it existed, its contents would be sent to the user's terminal, then deleted. MANAGER would take care of spooling the file if it was larger than the interactive output buffer size. Editor used TTYTTY to display output. This was a big win for Editor, since the normal interactive output buffer could store only about 5 lines. This meant that ordinarily, if an interactive program displayed more than about 5 lines at once, the job would be swapped out, then swapped back in when the buffer had been sent. With spooling of TTYTTY, Editor rarely had to be swapped out. It would load and run quickly, usually in a single time slice, and then exit, leaving the output chores to MANAGER.
One disadvantage of this run-quickly-then-exit approach is that no Undo
command was available. When Editor exited, it left no trace of what
the last command had been. Because Editor ran and exited for
essentially every command, this meant there was no history available for
any sort of Undo. If you entered DELETE *ALL
, you were
hosed. Fortunately, the system was backed up to tape religiously
every night.
In addition, the need to SAVE a file every time you needed to compile or otherwise process it certainly worked against Editor's efficiency.
EDITOR is documented in the SCOPE/Hustler Interactive System Users Guide. (This is a PDF file, so you'll probably want to right-click and choose Save Target As or the equivalent.)