🚀 go-pugleaf

>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?