Aucbvax.4232
fa.editor-p
utzoo!decvax!ucbvax!editor-people
Mon Oct 5 15:28:52 1981
Forwarded note
>From sklower Mon Oct 5 15:28:37 1981
You may have seen this already, but just in case . . .
Mail-from: ARPANET site CMU-10A rcvd at 1-Oct-81 1705-PDT
Date: 1 Oct 1981 11:41:33-PDT
From: CSVAX.wilensky at Berkeley
To: CSVAX.emacs@Berkeley, CSVAX.wnj@Berkeley
Subject: emacs and unix
Cc: arpavax.fabry@Berkeley
Via: 1.78.0; 1 Oct 1981 1603-EDT
Remailed-To: :INCLUDE: "DSKB:EMACS.DST[N310UE00]" at CMU-10A
Remailed-From: Unix Emacs at CMU-10A
Remailed-Date: Thursday, 1 October 1981 1853-EDT
Remailed-date: 1 Oct 1981 2236-PDT
Remailed-from: J. Q. Johnson <ADMIN.JQJ AT SU-SCORE>
Remailed-to: editor-people at SU-SCORE
Emacs poses some interesting systems questions whose resolution is
unclear to me. Here's a long-winded rendition of one of them.
Perhaps some of you have ideas about the best way to go:
The problem is, how does one integrate the systems functions of terminal
input, editing, buffering, and display/window management? The assumption
in unix (and in most operating systems) is to divide up these functions
as follows: you have a program called an editor that's used to edit files;
by necessity it does some buffer management. You have another program that
receives input from the user and transmits it to some process, and another
that displays output. Basically, these are thought of as autonomous functions.
It strikes me that this whole division is the wrong way to cut up the pie.
For example, one needs editing functions of various sorts when one does
input to a program, say to the shell. The typical solution is to supply
the input routine with its own simple editor (e. g., ctrl-h means "delete
last character" when you talk to the shell). As the need for more editing
functions becomes apparent, more features are hacked into individual input
routines, so ctrl-w becomes "delete word", etc. In addition, the need for
buffering also creeps in - one wants to be able to get back a previous
command, for example. The result, if done well, is something like
Bill Joy's history mechanism, which is essentially buffering and editing
functions added to the shell.
Now, nice as this mechanism is, it falls short of having the full power
of an editor like vi or emacs available to edit commands or manage a buffer.
Moreover, it really goes against one of the most positive attributes of
the unix's philosophy, that of composibility. The nice thing about unix
is that I can tie programs together easily into powerful functions. In this
spirit, I would like to compose together the power of a full editor with
the power of the shell. But current divisions of labor resists this approach,
and instead, reduplicates already existing functions.
In fact, the current ideas about window management are to build a separate
window manager. However, I think we will end up reduplicating in
this program its own editing/buffering functions, for example, to deal
with moving text between windows or to support "virtual windows" that
need not all be on the screen at once.
Emacs provides one solution to this problem - Put all these functions
inside one program, and run a shell (or whatever) "inside" an emacs buffer.
This enables you to compose the full power of a window manager with an
editor, a buffer manager and program input functions. However, there
are some potential drawbacks:
1) This ties everyone to a single editor (and window manager, and ...).
John Foderaro's vi-lookalike not withstanding, it's not clear how
easy it will be to duplicate the full vi command structure within
this context (e. g., consider "undo"). Moreover, it is probably
desirable (and in accordance with unix philosophy) to allow each
user to use an editor of his choice. Again, the ideal solution,
in the spirit of unix, would be a system where an arbitrary editing
command structure could be composed with these other functions.
(Counter - one might claim that the flexibility of Gosling's mlisp
based system will make it easy for a knowledgable user to implement
any editing command structure, or that effort should be directed
to make this possible).
2) There is something disturbing about lumping everything into one big
program. Maybe this only seems like lumping because we are used to
a previous (and I claim, erroneous) distribution and duplication of
these functions - really what we are describing is simply a comprehesive
i/o manager/editor, and thinking that one could separate these functions was
wrong to begin with. Individuals could still run their own hand-tailored
i/o manager/editor, I guess. But I'm still afraid of losing some
composibility here.
3) Some thought needs to be given to real window management in emacs. For
example, suppose the process associated with a buffer/window wants to
do cursor addressing. A smart window manager should be able to translate
the process's i/o to the correct physical location, but some mechanism
for running a window in this kind of mode must be available. I suspect
(but don't know) that this problem is no worse in emacs than it would
be with a separate window manager.
In addition, there are the problems of the interaction of the above with
terminal editing/buffering capabilities, and moreover, with jobs control
facilities.
Comments?
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
