Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!teklds!zeus!bobr From: bobr@zeus.UUCP Newsgroups: comp.sys.apollo Subject: Re: Aegis Vs. Unix Message-ID: <1819@zeus.TEK.COM> Date: Tue, 9-Jun-87 17:14:16 EDT Article-I.D.: zeus.1819 Posted: Tue Jun 9 17:14:16 1987 Date-Received: Sat, 13-Jun-87 02:00:34 EDT References: <8706090628.AA29741@zeus.CS.UCLA.EDU> Reply-To: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix Inc., Beaverton OR Lines: 87 In article <8706090628.AA29741@zeus.CS.UCLA.EDU> srt@CS.UCLA.EDU writes: It seems to me that many of the people who are dissatisfied with the Apollos are people who come from a one-window, command-line oriented operating system like Unix. In that kind of environment, Emacs running sub-processes is a dream come true, because it gives you a kind of multi-window functionality. That comes for free on the Apollos - you can liberate yourself from this kind of one-window thinking. Give me a break! I am quite familiar with windowing systems, their strengths, and their weaknesses. One common failing of windowing systems is that there is no choice but to treat each window as a separate virtual terminal with a completely different environment. With no context, everything must be specified in a fully qualified form. While running Emacs with multiple windows, a context is established and shared among the subwindows managed by Emacs. Functionally, this is no less a windowing environment than the "true windows" provided by the DM, but in some respects, it is more. This shared context can provide a level of cooperation among windows that is not easily obtained in the DM windows model. You can't simply look at the Aegis command-line interpreter independent of the environment it operates in. Sure, if you want to fire up your Apollo with one window and treat it like an extremely expensive workstation, you are going to be dissatisfied with the environment. I normally have a minimum of four windows running. One contains an emacs process with up to five or six separate panes. One is used for compiling and running programs (I still haven't been able to solve the AEGIS bug which causes some Emacs subprocess support to hang). These first two tile the entire screen (excluding the DM command line). I also have a window for the debugger, though I would rather run this as one or more panes in the Emacs window. A forth window runs /com/sh, because /bin/csh still has some bugs in it that prevent some programs from running properly. Running them under /com/sh seems to alleviate the problems. As I said in my previous post, I generally will work a system to its limits. I have not ignored the capabilities of multiple windows, but I have discovered their weaknesses. You don't need to run your editor and your debugger in the same window. Run them in different windows and move between them however and whenever you want. Share information, cut and paste, etc. Consider the advantage of running the debugger as a subprocess of your editor. The most obvious advantage is simple navigation about a multi-file program. I don't need to type "env MCHAN_C\create_process\" to get to that context for debugging. I just "^X^Gcreate_process^J" which takes me right there. I can brouse the file easily without concern for line numbers. I don't need to guess at line numbers and have "env" tell me that such and such a number doesn't exist. When I find the line I want to breakpoint, I have a function key mapped to "ESC-Xdbx-break^J" which computes the line number and feeds a command to dbx to actually place the breakpoint. Other function keys have been similarly mapped to functions for single stepping, printing values and continuing to the next breakpoint. When I discover a bug, I'm generally right at the place I need to be to fix it Multiple DM windows offer no advantages over this method of debugging. It goes without saying that I do have another window which is actually running the program I am debugging. Much of the functionality of the C-shell isn't needed on the Apollos. I rarely use the history functions (!!, etc.) on the Apollos because "Again" and C&P are so much handier, and I'm sure there are other examples. "again" and "cut and paste" are a bearly adequate replacement for csh history functions. The problem is interposed program output, which causes command lines to be scrolled off the page, requiring a lot of keystrokes to find an reexecute commands. A better solution than either of these is the technique used in the ksh where simple key sequences pan back through the history file, selecting those lines which were specifically entered as commands. I'd rank the csh second in usability of this function and the DM last. I don't think the DM editor is a joke, though it obviously is not nearly as flexible as a powerful Emacs. Many of the most common editor functions are supplied in the DM, and the most important customizations can be handled (key binding, macros). I disagree that the DM provides facilities for performing the most important customizations. It provides facilities for supporting the most easy to implement customizations, i.e. simple string replacements. There are some important things that can be done, such as binding SHELL to /etc/start_csh, but the lack of conditionals and parameters means that lots of simple functions which are easy to produce in other macroprocessors are impossible to do in the DM. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK