Message-ID: <bnews.ucb.1181>
Newsgroups: fa.editor-p
Path: utzoo!decvax!ucbvax!C70:editor-people
X-Path: utzoo!decvax!ucbvax!C70:editor-people
From: C70:editor-people
Date: Sat May 29 03:15:32 1982
Subject: Re: EDITOR discussion on TOPS-20
Posted: Tue May 25 21:16:48 1982
Received: Sat May 29 03:15:32 1982
>From RWK@SCRC-TENEX@MIT-AI Tue May 25 19:22:34 1982
[Editor's note: I have taken the liberty of appending two related messages
from RWK into this one message. The first message advertises itself as
"flame", but both present a great many important observations. /jq]
I'm getting tired of seeing a barrage of opinions in the form of
dogmatic statements. I think it's about time I make a few strong
statements of my own.
Date: 20-May-82 9:36PM-EDT (Thu)
From: Steve Wood <Wood at YALE>
I have already implemented a change to TOPS-20 that provides a
significant improvement in the interactive response time of a display
editor, while at the same time reducing the number of process wakeups.
It works and is in use everyday here at Yale. My suggestion is that
EMACS could be changed to take advantage of the changes to the monitor.
What would have to be changed?
There should be a one to one mapping between file positions and display
positions. This would require long lines to be clipped instead of
wrapped;
This is completely, absolutely unacceptable. Any editor which hides long
lines is completely unusable in many environments, such as any environment
I've ever been in. Such an editor is BROKEN, a mere fragment of an editor.
The change is also completely gratuitous, since it is quite acceptable to
wake up the editor in this unusual case.
control characters to be displayed as a single high-lighted
character; tabs to be expanded to spaces;
This isn't acceptable either, since EMACS supports that majority of terminals
that don't have highlighting modes. It is also doesn't buy you anything.
If you're really going to do up/down cursorpositioning commands in the monitor
(which I don't think would make an appreciable difference) then just position
it. Let the editor figure out the mapping when it finally gets control and
finds out the new cursor position. Inserting into the middle of the tab
would require the editor to handle it so it could move the cursor before
inserting to the begining of the TAB, but this would be no more disconcerting
than the current TAB behaviour. Actually, maybe it should instead just insert
the necessary spaces actually put it in the place the cursor moved to. THAT
would be an improvement, I think. Converting the file's tabs to spaces and
making the user work with spaces is a fine user-interface idea, but ignores
the reality that the files may NEED tabs for whatever program.
next/previous line and
forward/backward character to move by screen positions and not by file
positions.
They already *DO* work by screen position. What they DON'T do is extend a
line beyond the end. It should be no problem to tell the monitor where the
line ends, if you really wanted to do this.
Would these changes be fatal to EMACS users? I don't see
how as they would only improve what is already a very good editor.
I would refuse to use it. So would a lot of other people, I'm sure. I'd
keep around a non-performance-enhanced version and use that instead.
Many editor designers have taken the attitude that they know better than
the designers of EMACS what an EMACS-child should look like. It has
been my experience that they have often been very, very wrong. EMACS
was in a very real sense designed on the experiences of a very large
community of users, and end up breaking some of the most important
features. This does not mean that an editor has to be identical before
I would accept it. But I do wish people would not start calling
features very many people consider essential "obsolete" and such.
And don't underestimate the importance of compatibility in command
sets. Editor designers don't seem to realize that people who use
their editors use other editors too. I find that all the good ideas
in the world can't overcome an incompatible command set (especially
if the editor isn't extensible enough to fix it!) or a single bad
idea like line-truncation.
So please, I really don't want to hear more about changing EMACS's
COMMANDS to make it easier to implement the monitor.
I think this is more of a TOPS-20 issue than it is an editor issue.
Certainly, if you are only going to try to make improvements in the
performance of a specific editor. I think such an attitude is a mistake
when making changes to an operating system.
It seems to me that you're trying to redesign the editor around the operating
system. This has to be the biggest mistake of them all. I consider the
attitude of "operating system efficience over user interface" to border on
criminal. And all for the sake of optimizing what will be a minor fraction
of the commands -- I can only shake my head in disgust.
----------------------------------------------------------------
Date: 22-May-82 1:24AM-EDT (Sat)
From: Steve Wood <Wood at YALE>
Date: 20-May-82 3:06PM-EDT (Thu)
From: Steve Wood <Wood at YALE>
However the design of EMACS is such that you could not change
the stream editing model that EMACS presents to the user. The
mapping between file positions and display positions is buried
at the lowest level of the implementation. I know this is
true of the TECO implementation and I suspect it is true of
the LISP-based versions of EMACS.
I wish I knew what this meant. If I did, I might be able to tell
you about some of the LISP-based versions of EMACS.
In order to make the mapping between file positions and screen positions
be one to one, the following changes would have to be made.
Unfortunately not all of these changes are not possible using the
extension language and the editor kernel itself would have to be hacked.
First tabs would have to be stored as spaces, by changing the tab
command to insert the appropriate number of spaces instead of a single
tab character. You would also have to hack file input to convert tabs
to spaces. Control characters are displayed as two characters, which
can't be changed without hacking the low level display primitives.
Long lines are wrapped onto succeeding lines. Making it so they are
clipped instead would also require modifications to the low level
display routines. All movement commands could be changed to allow
movement to non-existent file locations, by automatically inserting
enough blanks so that the file does exist at the cursor location. If
you did this, you would have to change the file output logic to remove
any extraneous blanks caused by moving the cursor past the end of a
line or the file, but not making any other changes.
Probably all of this is doable with existing Emacs implementations,
except for the modifications to the low level display routines, as
the redisplay algorithm is not accessable to the user. I don't know
what affect these changes would have on other Emacs commands.
-Steve
Well, in all LISP-based editors I know of, tabs are stored as Tabs.
(Ten-space-wide in Multics EMACS). I went into why this is necessary (we
know why it is unfortunate) in my recent flame. I might try making ^N
do the "right thing" with Tab's in ZWEI (the base for the ZMACS editor
on the Lisp Machine which is also used in a number of contexts which are
not strictly text-editing). I.e ^N would move the cursor to
more-or-less the right place, and if you tried to insert there it would
add enough spaces. The redisplay algorithm is available to the user in
all the Lisp-based editors. (This doesn't mean the code is easily
changable, but any user can replace it in his init or whatever).
I say "more-or-less" because of another problem: The 2-D array of
fixed-width characters model is bankrupt and obsolete. Documents
and even programs make use of fonts of variable widths. TAB's are
not the only character which is of non-standard width! ZWEI tries
hard to move as close to the same vertical position, since the 2-D
array is one of many competing models which are useful to the
user in various circumstances.
The "stream" of characters model that you so despites is another model
which has its own uses. So much so that the Lisp-based editors provide
it to users (in addition to the 2-D array model, the paragraph model,
etc), despite the fact that they do not represent it that way internally
at all. In at least ZWEI and Multics Emacs, text is represented as a
doubly-linked list of lines.
This wealth of different models for the text is one of the things that
makes EMACS so powerful. It also means that optimizing ^N and ^P is not
that important. Look to your M-A and M-E (forward and backward
sentence), your M-B and M-F (fowrdard and backward word) etc. If these
commands cannot respond adaquately fast, I would seriously recommend
against buying that machine. Building them into the monitor is not the
way to go!
What is needed is to optimize the most common ones to minimize the load
on the system. (I've seen somewhere a frequency table of various types
of commands in some EMACS-like editor. My recollection is that C-N and
C-P were down in the noise; I'm sure this is true of my own usage. Does
anybody recall seeing these statistics somewhere?) Echoing and
sequential paging are the only reasonable canidates for further monitor
support that I can believe in without solid frequency-of-use statistics
to back them up.
Message-ID: <bnews.ucb.1199>
Newsgroups: fa.editor-p
Path: utzoo!decvax!ucbvax!C70:editor-people
X-Path: utzoo!decvax!ucbvax!C70:editor-people
From: C70:editor-people
Date: Sun May 30 00:46:33 1982
Subject: The Recent Roast
Posted: Thu May 27 06:39:35 1982
Received: Sun May 30 00:46:33 1982
>From C70:daemon Thu May 27 01:08:32 1982
I have just reviewed the set of messages that have been flying over
TOPS-20 and E-P. I am afraid things got really out of hand. A little
background is in order.
At Yale, for better or worse until recently we were isolated from the
rest of the TOPS-20/Emacs world and hence developed a lot of our own
software. We have a slightly different (note I didn't say "better")
tradition of screen editors. Yale editors have stressed aspects of
editing different from Emacs. We do not consider ourselves amateurs
on the subject of editors and resent the attitude that "Emacs has solved
all these problems and why are you telling us about your bogus editor".
The basic style of Yale editor has been in use here for 10 years; people
like it. The current Yale editor, Z, has been in serious, production
use for several years.
I would like to think that discussions about differences between Z
and Emacs could be to each's benefits. Let's not all get our defenses
up so high that we can't learn from each other's experiences. Please
do not take any mention of problems with Emacs as an all-out attack.
If some of our messages have sounded a bit extreme it is only because
being in a minority we feel we have to speak strongly so people will
notice our alternatives. Despite this, I think some people reacted
over-defensively to Steve Wood's first message.
At Yale, only 2 people out of a community of hundreds of users use
Emacs over Z. This is not to denigrate Emacs; Emacs is a very
good editor and has many features Z lacks (note also that Z has features
that Emacs lacks). My point is that we should all have realized that
arguments of the form:
(Editor X has n-hundred users & has feature Y) =>
(feature Y must be necessary for a good editor &
any editor which doesn't have it must clearly be inferior and useless)
are just not credible. People use all sorts of editors for all sorts
of reasons not necessarily having to do with the quality and features
of the editor compared to other editors (e.g. it was the first one
they learned; it is the one that is supported best at a particular
site; use of other editors is socially frowned upon). We all know
this, don't we? I am not ashamed to say that a main reason Z is used
most heavily at Yale is because it was here first, and is well-supported
here. I would be hard-pressed to believe that the Emacs story is much
different at the sites at which it is used. I don't think anyone has
the ability to fully factor out the incidental reasons for a particular
editor's use in judging an editor's quality. Thus, I think for the
purposes of electronic forums I think we would do well to stay away
from issues of features near and dear to various people's hearts
(believe me -- I am probably as grossed out by lines being wrapped
at the right as you are about their being invisible off the right;
what does it prove? I believe you when you say you like wrapping better
and I would hope you would respect my preference).
The core of the original discussion was monitor support to improve
the performance of editors. My reaction to the proposed TEXTI changes
is that people were not thinking about the more global issue: how
does the implementation and user interface of an editor affect the
kinds of things one might reasonably consider adding to an OS to
increase the performance of the editor? That is, if you are interested
in improving performance, when do you consider changing editor styles?
Or to put it another way, when do you not bother to not strive for
the last iota of efficieny in an editor that has design properties
that prevent significant optimization along a particular dimension?
Subtract out any parts of Steve Wood's message that you might find
offensive and what you have is not an attack on Emacs. Rather you
have a statement that says: look what different (and hopefully more
extensive) kinds of support you can give to an editor if it has a
particular model. Whether you like the style or not is another matter.
Suffice it to say that some large number of people like the Yale-style
editor enough that someone (Steve) considered techniques to support
it in the OS, then implemented those techniques and got a significant
win out of it. This information should be added to the editor
designer's bag of information he uses when building editors. It is
up to him to evaluate the model AND the efficiency of implementation.
Say, if he (and his user community) are ambivalent between the 1-D
and 2-D models he can use this piece of (dare I say "experimental")
information to help in making his choice about which model to use.
-- Nat
-------
Message-ID: <bnews.ucb.1235>
Newsgroups: fa.editor-p
Path: utzoo!decvax!ucbvax!C70:editor-people
X-Path: utzoo!decvax!ucbvax!C70:editor-people
From: C70:editor-people
Date: Wed Jun 2 03:07:22 1982
Subject: evaluating editors
Posted: Tue Jun 1 16:23:21 1982
Received: Wed Jun 2 03:07:22 1982
>From reid@Shasta@Sumex-Aim Tue Jun 1 16:07:50 1982
The issue of getting users for text editors, and of Yale's isolation,
is important, and I'd like to comment on it a bit.
In this systems business of ours, it is extremely difficult to evaluate
the quality of a piece of work. There are no mathematical proofs to
read through, no pages of data and graphs to peruse, no airtight
physics experiments that can be run to check hypotheses. Instead we
rely on our designers' instincts, evaluating systems as we explore
them. If a system is good, we might use it, steal its ideas by copying
it, rave about it to our friends, or even in some cases abandon
everything we had been doing to make the incompatible change to the new
system. If a system is bad, we might ignore it, poke fun at it, flame
at how ignorant it is, or perhaps try to evaluate why it is bad so that
we (collectively) do not make that mistake again. Sometimes systems are
bad because they are based on bad models; other times they are bad
because they are programmed badly; perhaps they are bad because they
are internally inconsistent. There are many reasons that systems can be
good or bad.
In about 1976, or thereabouts, we at CMU (where I was at the time) got
a copy of the source and documentation for the Yale Editor "E". Craig
Everhart and I struggled valiantly to get it running, and after burning
the better part of a month on it, we gave up. It was written to run
under Tops-10, but it assumed the existence of very extensive changes
to the monitor, including the dreaded SCNSER. It was politically
unacceptable at CMU to make such major and incompatible changes to the
monitor, and it just wasn't going to work without them, so we stopped.
"E" also was written to use a particular terminal (I forget the brand)
and no other, but the manufacturer of that terminal had gone out of
business. So we couldn't even dial Yale long distance and use the
editor over the phone: we didn't have the right brand of terminals. So
despite our interest in exploring this interesting-looking editor, we
were not able to evaluate it properly because we could not use it.
At about that same time, give or take half a year, the EMACS editor
started appearing on TOPS-20 systems around the network. I had access
to SRI-KL, and EMACS supported all of the various terminals that were
around. I was able to use EMACS, learn it, and assimilate its ideas.
Naturally I think that EMACS is the better of the two editors, because
I was able to use EMACS and not just hear about it. When I teach
students about text editors, I include the EMACS model of editing as a
major focus, and I don't even mention the existence of either "E" or
"Z" from Yale, despite my beliefs that they might actually be good
editors.
Now my primary computing comes from a VAX Unix, Shasta, and on that
system we can run three worthwhile editors: Jim Gosling's EMACS, Rand's E
(a.k.a. NED), and Bill Joy's VI. I don't know who at Rand is the main
force behind E. And as I think and talk about editors, it is very
convenient to be able to draw examples from these three working models.
From what I've heard about Yale's Z, its editing model is fairly
similar to Rand's E, but since Rand's E is exportable and fairly
universal, while Yale's Z is not, I will probably end up associating
and attributing those ideas to Rand and not to Yale.
The moral of my ramble is this: if what you are trying to do is to
write a good editor for your own people to use, then you are free to do
whatever you want. If what you are trying to do is influence the
opinion of the C.S. research community, and hence the directions and
ideas of future editors, you have to make your system available to them
to be evaluated. These people are not fooled by rhetoric nor persuaded
by hearsay.
Brian Reid
Message-ID: <bnews.ucb.1250>
Newsgroups: fa.editor-p
Path: utzoo!decvax!ucbvax!C70:editor-people
X-Path: utzoo!decvax!ucbvax!C70:editor-people
From: C70:editor-people
Date: Thu Jun 3 05:52:54 1982
Subject: Re: evaluating editors
Posted: Thu Jun 3 01:18:35 1982
Received: Thu Jun 3 05:52:54 1982
>From Mishkin@YALE Thu Jun 3 01:14:55 1982
I fully sympathize with your painful experience trying to bring up
bogus software. In case it is still not clear: Z runs on unmodified
TOPS-20 systems as well as on our own modified monitor. I completely
agree with you that exporting (or "exporting") software which has
bizarre monitor dependencies is totally unacceptable.
I can not comment on earlier generations of Yale hackers from which
the present Tools (incl. Z) work is totally divorced. However, we
have strived very hard to make our software robust and exportable.
Every single tool we send out is documented. All our code is written
in a high level language (Bliss; higher than MACRO anyway) and uses
a shared runtime library. Z is terminal independent and it is very
easy to add new terminal types to Z since it uses a termcap-like
facility (i.e. it uses terminal descriptor files).
In characterizing our "isolation" I should have mentioned that, to a
certain extent, in retrospect we consider this a boon: had we been
on the net, we probably would have absorbed that large set of random
programs written in MACRO instead of developing a coherent set of
utilities and a environment for writing them.
-- Nat
Message-ID: <bnews.ucb.1272>
Newsgroups: fa.editor-p
Path: utzoo!decvax!harpo!npois!ucbvax!C70:editor-people
X-Path: utzoo!decvax!harpo!npois!ucbvax!C70:editor-people
From: C70:editor-people
Date: Sat Jun 5 01:30:26 1982
Subject: Re: evaluating editors
Posted: Fri Jun 4 03:37:36 1982
Received: Sat Jun 5 01:30:26 1982
Reply-To: ople
>From gaines@RAND-UNIX Fri Jun 4 03:32:14 1982
Since I have been associated from the beginning with a family of related
editors, it seems appropriate for me to discuss some ideas in the context
of the history of those editors. The daddy of them is an editor developed
by Ned Irons in 1967 at the Institue for Defense Analyses (IDA) in
Princeton. Ned designed and implemented a timesharing system for the CDC
6600, and as part of it designed what we at the time called a "full screen"
editor, to distinguish it from line-at-a-time editors. The decendents of
this initial editor include E at Yale (where Ned went in 1969), NED at Rand
in 1964 (guess where the name came from) (done by Walt Bilofsky, now the
Software Toolworks), and (as a copy of NED) the Apple Pie editor. Dave
Crocker worked briefly extending NED while he was at Rand, but the real
extensions which transformed it into the current E editor from Rand were
done by Dave Yost. The lastest version, with really quite a lot of
goodies, is E15. Those who want information about it should contact Mike
Wahrman <Mike at Rand-unix>.
The original editor had very little: forward and back a page (screen) or
line, cursor movement and insert. Ever heard of insert? It didn't mean
insert mode, in contrast to overwrite mode. The controller for the
terminals available in 1967 required a separate function key that was
interpreted to mean that the screen was now correct, and therefore could be
inserted in the file. The individual keys were not passed back to the 6600
as each character was struck. Instead the refresh memory (stored in the
controller, which supported several terminals) was modified. I mention
these details because the hardware strongly colored the model of editing
that evolved. The hardware made it essential to view the screen as a
blackboard with a little peice of the file on it. The non-function keys
and the cursor control buttons allowed one to rearrange his little
blackboard, and then later indicate by hitting "insert" that this was how
the file being edited should now be updated.
The terminals were specially modified to have many function buttons, and as
time went on new functions began to be added to the IDA editor. However
they never included an insert mode capability, since the hardware couldn't
support it. Thus the intial orientation of this class of editors was
determined.
As an aside to a discussion of purely editor matters, in the IDA system the
command executive was invoked from within the editor, and as a consequence
the system had some very pretty aspects. Until I saw the Multics command
executive being invoked from within EMACS, I was not able to find another
system that could provide some of the nice effects that this permits.
As I said, Irons' initial editor didn't have very much. But you could get
a lot done. Almost immediately, though, Franz Djorup (still at IDA)
started extending the editor. Eventually he and Irons published a paper in
CACM (early 1971, I believe). The great leap forward was the invention
"pick" and "put" (sugggested by Bob Cave, who is also still at IDA). In
this class of editors "pick" and "close" copy lines to a temporary buffer
("close" also deletes them from the file) and "put" copies these lines from
the buffer to a designated point in the file. Before these came along,
various attempts to write programs that would rearrange a file in a nice
way were tried, all almost unuseable. The capability to rearrange a file
by marking sections, together with the ability to move a cursor around the
screen, are among the prinicipal elements that make editors powerful, in my
view.
The Yale E editor had some extensions from the IDA editor, and some
changes, but retained the flavor of the IDA editor. I have not seen it in
10 years, and don't remember its details, but I recall noticing at the time
that the most striking differences bore a relation to the hardware being
used (the PDP 10 running TOPS 10, and the funny terminals Irons found --
made by Sugarman, I vaguely recall). Insert mode was possible with that
system, I think. Someone with more experience may wish to comment on the
major features in E that differ from the IDA editor.
The major advance made by Bilofsky was to free the editor from line size
limitations and to permit the use of several windows on the same CRT. This
required dealing with issues such as what to do when the two windows were
displaying some or all of the same section of a file, and a change was made
in one window. Bilofsky also added the capability to execute a command
from within the editor, possibly sending a marked block of the text being
edited as input to the command. This was doable with reasonable effort
because of Unix pipes and the way the Unix shell works.
The E15 editor of Dave Yost is Bilofsky's NED in spirit, but reworked from
the ground up. Many new features have been added. Everyone seriously
interested in editors should look at it just for the range of ideas it
displays.
I haven't seen the Yale Z editor, but I would suspect derives from the
editors already mentioned. Various people were going back and forth
between Yale and Rand during the 1970's, including Ned Irons. Again,
others familiar with it may wish to comment.
With the Rand editors, the model I described above has changed slightly.
Now a better model is that the editor supports a workspace that extends
indefinitely to the right and down, and that may be initialized with the
contents of a file. The screen is a window into this workspace. The user
can position his window to display any portion of the workspace, and can
move his cursor where he will within the window. For activities that do
not involve insertion of characters, the analogy of a blackboard that
extends indefinitely to the right and down is quite good. Insertion of
lines, characters, or blocks (multiple lines or line fragments) cause
immediate movement down or to the right of some of the blackboard. One
need not, when using a blackboard, explicitly supply white space (black
space??).
The E15 editor embodied so many features that I though it was getting to be
about as good as one could expect in an editor. Then I saw EMACS. It was
a surprise and a delight to me as a computer scientist. I found the idea
that one could build in some knowledge of the domain of the text being
edited very exciting. This clearly is a step in the direction we keep
striving to go with computers: reduce the work of someone using a computer
by having it do as much as possible under the user's control. Furthermore,
the fact that to a degree it is possible to build in additional knowledge
is another large plus.
Having seen EMACS, I got another suprise when I saw my first good word
processor. While not extensible as EMACS is, knowledge of some nice
aspects of printed language are built into the best of them that do not
appear in general-purpose editors. A real effort has been made in them to
follow the idea of "what you see is what you get", in contrast to the edit
+ nroff approach in which most special formatting is simply described for a
later pass through a formatter. There is a limitation, though, to the
"what you see is what you get" approach: terminals cannot display what can
be printed. This is true at the top end of the quality scale, in that
typsetters and printers can do things that even the high resolution bit-map
terminals being offered today cannot do. It is also true on a relative
scale; the cost of good display quality terminals is high relative to the
cost of printing equipment for organizations that need lots of terminals.
In closing this note, I would like to make some comments about the 2D
versus 1D debate that has been going on. The model I have described above
is a slight extension of the 2D view. It seems to me that this model is
more general than the "edit-the-file" model (I don't think the term 1D is
very descriptive of what goes on in EMACS). It seems to me that the cases
when one must append white space at the right end of a line or after the
last line in a file are so rare that it is best taken care of by a file
reformatter, and that aside from this capability the "indefinite
blackboard" model gives the user more power than the edit-the-file model,
while giving up nothing else. Certainly it is nice to be able to position
the cursor by reference to the semantic constructs the editor has been
taught to recognize. But as when making marks on a real blackboard, it is
also nice to be able to get to a point in the workspace independently of
these semantics. I think the edit-the-file model is simply restrictive to
no significant advantage. Unfortunately, at least in the LISP version of
EMACS on Multics, I don't think it is changeable through EMACS extensions,
but rather would require major surgery. Those who only have familiarity
with the edit-the-file model should take a look at the many goodies related
to the indefinite blackboard model Yost has built into E15 to see how much
power that model really has.
Message-ID: <bnews.ucb.2201>
Newsgroups: fa.editor-p
Path: utzoo!decvax!ucbvax!ARPAVAX:C70:editor-people
X-Path: utzoo!decvax!ucbvax!ARPAVAX:C70:editor-people
From: C70:editor-people
Date: Wed Oct 27 03:41:01 1982
Subject: Z editor usage statistics
Posted: Mon Oct 25 08:32:08 1982
Received: Wed Oct 27 03:41:01 1982
>From Wood@YALE Mon Oct 25 08:01:24 1982
For the past three weeks, I have been collecting statistics about the
usage of the Z editor here at Yale. We have two DEC2060's, connected
to over 400 terminals campuswide, via a Gandalf PACX box. The majority
of the terminals in use at Yale are Datamedia 1521s, running at 9600
baud. The user community includes students, faculty and staff of the
Computer Science Department, as well as many users from other
departments.
Highlights:
- over 22,000,000 inputs, 5500 hours of elapsed time in the editor
(45 hours of CPU time).
- Users spend more than half their time on the computer using the
editor.
- Graphic characters + cursor keys account for almost 90% of user
input. Editing commands and window movement commands account
for an additional 7%, with everything else in the noise margin.
- 85% of all characters echoed in insert mode, are past the end
of the line and thus can be echoed as if the editor is in replace
mode. For users that run in insert mode all the time, the figure
is over 90%.
- The local modifications to the TOPS-20 operating system that do
immediate echoing of graphic characters and cursor keys, echoed
75% of all input characters in real time. Currently the editor
does not take advantage of end of line echoing when in insert
mode. If it did, this figure would be closer to 82%.
The following is a summary of the statistics for all terminal types
and skill levels. If you are interested in a further breakdown, you
can FTP the following files:
[YALE]/usr/anonymous/z-term.stats
subtotals by terminal type (Datamedia, Ambassador, TVI, Apollo, etc.)
[YALE]/usr/anonymous/z-skill.stats
subtotals by skill level (novice, intermediate and expert).
[YALE]/usr/anonymous/z-detail.stats
same as what follows, except with details on graphic character
frequency and command argument usage.
Editor usage:
Total Elapsed time: 10886:58:24
Editor elapsed time: 5574:23:17 51.20%
Editor CPU time: 44:59:20
Editor invocations: 79117
New editor started: 10806
Old editor continued: 68311
from parent process: 22429
from Session manager: 45882
via sm escape: 37592
via sm command escape: 4762
via sm program escape: 3528
Input statistics:
Total command input: 22826481
graphic characters: 10010397 43.85%
replace mode: 8151386 35.71%
insert mode: 1859011 8.14%
within a line: 258549 1.13%
past end of line: 1600462 7.01%
editor commands: 12361970 54.16%
cursor commands: 10296336 45.11%
right 3991580 17.49%
left 3308209 14.49%
down 1461983 6.40%
up 802373 3.52%
newline 551727 2.42%
tab 121189 0.53%
home 20258 0.09%
endLine 9695 0.04%
pWord 7800 0.03%
mWord 6501 0.03%
setCursor 6324 0.03%
begLine 3239 0.01%
backTab 2401 0.01%
mParagraph 1728 0.01%
pParagraph 1329 0.01%
editing commands: 1192967 5.23%
cDelete 421556 1.85%
sDelete 336097 1.47%
sInsert 159025 0.70%
lDelete 100707 0.44%
lInsert 96793 0.42%
put 43032 0.19%
pick 16690 0.07%
wDelete 15217 0.07%
replace 2918 0.01%
qReplace 932 0.00%
window commands: 432235 1.89%
pLines 144801 0.63%
pPages 90110 0.39%
mPages 64676 0.28%
pSearch 46158 0.20%
mLines 39848 0.17%
mark 23044 0.10%
mSearch 17903 0.08%
setWindow 5695 0.02%
basic commands: 209297 0.92%
arg 165311 0.72%
insertMode 20674 0.09%
cancel 13089 0.06%
meta 6025 0.03%
noFunc 1672 0.01%
quote 1417 0.01%
nop 652 0.00%
textArg 457 0.00%
file commands: 71871 0.31%
setFile 71121 0.31%
refresh 602 0.00%
undelete 148 0.00%
exit commands: 81313 0.36%
sm 45649 0.20%
exit 31220 0.14%
moveSM 4257 0.02%
push 187 0.00%
program commands: 57057 0.25%
balance 52991 0.23%
compile 3850 0.02%
comment 216 0.00%
document commands: 14945 0.07%
fill 7189 0.03%
justify 3119 0.01%
spell 2671 0.01%
upperCase 711 0.00%
lowerCase 384 0.00%
capitalize 360 0.00%
center 286 0.00%
flushLeft 183 0.00%
flushRight 42 0.00%
status commands: 5869 0.03%
information 3166 0.01%
assign 1367 0.01%
help 1031 0.00%
execute 155 0.00%
initialize 142 0.00%
save 6 0.00%
bExecute 2 0.00%
Macros: 2165 0.01%
Text argument input: 451949 1.98%
graphic characters: 421886 1.85%
movement commands: 13308 0.06%
editing commands: 16755 0.07%
Total input characters: 22875606
echoed by monitor: 17055341 74.56%
shifted with <shift>: 482539 2.11%
Cancel command usage:
#cancel interrupts: 1113
#cancelled arguments: 4570
#cancelled text args: 2369
#cancelled editors: 932
Number of autosaves: 38403
-------