Computer user I/O historical overview
Table of Contents
1 Overview of input/output devices and how Emacs and Vi came to be
1.1 Early input/output on computers
- Early computer usage typically used punched cards
for input. Originally used to control automatical looms in the early 1800s, then to tabulate the US census in 1890 (IBM essentially got its start here), punched cards were a natural input medium for computer programs. A card punch
was used to punch holes representing characters. Each card represented a single line of code. Large printers were used to print the resulting output on continuous feeds of paper. More capable card punches allowed copying of cards, and included a mechanism to replace/insert/delete characters - this is now known as "line editing" and could be argued to be the start of modern programming.
- Later, on-line devices combining the keyboard and printer into a
single unit were used, such as this Teletype
from the early 1960s (this one has paper reader, another popular form of input; these were originally used for long distance communication) or this DECWriter II
from the mid-1970s. Now it was possible to have a "conversation" with the computer where all commands and their output were printed on paper. Not surprisingly, the line editing functions available on card punches were implemented as interactive programs for use on these systems and became known as line editors. That is, you worked on the text in a file one line at a time. DOS 'edlin' is in this tradition, as is UNIX 'ed' (see "Actually using ed").
1.2 Video terminals
- As electronic components became cheaper, video terminals were
developed that included a keyboard and Cathode Ray Tube (CRT)
screen. These displayed a fixed amount of text that scrolled from
the bottom to the top. A typical example is the DEC VT100:
- Line editors could be used unchanged on such systems. Early
microcomputers, such as the Radio Shack TRS-80
implemented line editors with similar functionality (this is the kind of machine I learned to program on).
2 Full screen editors
- At this stage all user I/O was stilly pretty much just text, and, by
today's standards, these systems were hard to use - really!
However, video terminals had the ability to redraw the screen and
reposition the cursor relatively quickly. It didn't take long for
this to be used to greatly enhance editing capabilities: instead of
working on a line at a time, it became possible to see a screen at
a time, and have the screen automatically update and reposition.
Such full screen editors were usually extensions of existing line
editors. Indeed, both Vi and Emacs were originally built on
line editors. In fact, when you type
:in Vi, you temporarily communicate with the underlying line editor. - Instead of just manipulating a line at a time, full screen editors
need to do two conceptually different things: edit text and move
around. If you look at a close up of a VT100 keyboard:
you don't have a whole lot of extra keys (function or otherwise) to do this, and certainly no mouse. How do you use this limited "palette" to perform both editing and motion? Depending on how you answer this question, you get completely different kinds of editors.
- Bill Joy, who implemented the original Vi, decided that there would
be two modes: insert mode and command mode. In insert mode,
(most) keystrokes were simply inserted in the buffer being edited;
in command mode, keystrokes performed editor functions, like moving
the cursor; the escape key exited insert mode, while various keys,
such as
iandaentered insert mode. - Richard Stallman, who did the initial work implementing what is now
known as Emacs, went a different direction: each key could be
bound to a function. Regular keys, like
aand5were bound to the self-insert function. Control keys were bound to functions that did things like move the cursor around. Some keys entered a menu-like system. The idea was that common actions were on single keys, and less frequent ones were on longer sequences.
2.1 Modern times
It was soon found that Emacs could be taught within minutes or an hour to those with no technical experience at all. Multics Emacs: The History, Design and Implementation – Bernard S. Greenberg, 1979, 1996
Well, the short answer is, you should learn Emacs by using it for about a decade. Learn Emacs in Ten Years – Edward O'Connor, 2009
Gosling quizzed the audience by asking how many people "still use Emacs?" … "just stop!" Don't use Emacs, says Java's father – Rodney Gedda (Computerworld), 2008
- WIMP ("Windows Icons Mouse Pointer") interfaces became popular starting in the late 80s, early 90s and made computers much easier to use. It allowed "mere mortals" to make use of what computers could do. This was further enhanced by the introduction of web browsers and the World Wide Web. Just "point and click" and you are on your way. At the same time, a version of Emacs, called GNU Emacs was released and whose use snowballed. It became the defacto implementation and a lot of talented people added packages to it. To start using GNU Emacs today, you have to deal with both of these: it is harder to use than straight "point and click" and is huge because it has been accreting functionality for 30 years.
- Gosling has an interesting place in computing history - he wrote the first version of Emacs for UNIX (the one I learned on, as it happens), and also was one of the main developers of the Java language. In 2008 he was still working for Sun Microsystems, since purchased by Oracle, and had a vested interest in promoting Java. And he is absolutely right if you are only ever going to be programming in Java. While it is possible to work with Java code in Emacs, various Integrated Development Environments (IDEs) are much better suited to doing so.
My take is that Emacs is still worth knowing if you work with many programming languages of if you deal with a lot of legacy code for which Emacs has builtin support, which it probably does. It includes "everything but the kitchen sink" and is infinitely customizable: (almost) every key is a "hot key" and can be programmed ("bound") to do whatever you like; there is a full LISP interpreter at your finger tips to write such programs; and, there is a large complement of OS related functionality that, for example, allows you to run external commands and capture the output. Here are a few features that I use on a regular basis that I really miss in other environments:
- IDE-like environment - edit/compile/debug/run all within Emacs
- run a shell inside the editor that captures all the output and allows complete cut/paste to/from other files
- "edit" a directory - sort of like Midnight Commander, but right in the editor itself - can copy, delete, edit files
- regular expression search and replace
- evaluate LISP expressions for simple math:
(+ 3 2 1 4)gives10
2.2 Summary
