Text File

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 <jgoerzen@complete.org> 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.