Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!jade!topaz.berkeley.edu!pete From: pete@topaz.berkeley.edu.UUCP Newsgroups: comp.sys.amiga Subject: Re: Proposal for an Amiga Shell Message-ID: <2444@jade.BERKELEY.EDU> Date: Thu, 5-Feb-87 02:31:15 EST Article-I.D.: jade.2444 Posted: Thu Feb 5 02:31:15 1987 Date-Received: Sat, 7-Feb-87 11:30:13 EST Sender: usenet@jade.BERKELEY.EDU Reply-To: pete@topaz.berkeley.edu.UUCP (Pete Goodeve) Organization: University of California, Berkeley Lines: 178 Keywords: Amiga shell CLI Sili(Con:) windows Summary: Some comments on Mike Meyer's original proposal [This is a re-posting -- as far as I can tell I sent the first into the ozone somewhere. If you see it twice, my apologies.] In his response to my note that my "Sili(Con:)" command line interpreter already implemented some of his Shell proposals, Mike Meyer gave me a pretty good history lesson on command windows and so on. No disagreement -- I didn't mean to claim that I was the first to think of such a scheme (and he mentioned sources that I wasn't at all aware of). I wanted to point out though that such an interface does already exist for the Amiga. He goes on to say some nice things about Sili(Con:), which I appreciate. Thanks a lot, Mike. Anyhow, I also promised to think about his other proposals and comment, so (a month later) here goes: Mike Meyer writes in "Proposal for an Amiga shell": > >....... >The following paper presents a description of a shell called ms, >designed for a modern personal computer. Ms is not meant to be a >radical departure from typical line-oriented shells, but an >enhancement of such shells to use the capabilities of modern personal >computers...... > >The User Interface > >When running, ms normally has three windows open, the input window, >the history window, and the output window...... We've been through this already vis-a-vis Sili(Con:)... I have some more thoughts, though. I feel that the command window (I'll come back to why I didn't call it an input window in a moment) and the history should definitely be 'panes' of a single control window as they are in Sili(Con:). Matt's remark about clutter is valid, but I believe -- and use has confirmed -- that there isn't much of a problem as long as you can push the control window out of the way in a hurry when you want, and get it back just as fast. Sili(Con:) has 'hot keys' to do this. If the two windows were separate this would be a lot messier. I used "command" rather than "input" window because I feel strongly that the command "stream" should be kept separate from other interactions. I often first enter a string of commands that I want to execute in sequence, and THEN make responses to any prompts the commands may generate; or, even more critically, I may double-click a sequence from the history window. It's a big advantage to be able to "click-ahead" like that. I don't see any simple recipe for keeping commands and responses distinct if they come in through the same channel. And of course the history would get cluttered up with responses intermixed with commands. I personally would object to that, though I could understand if people wanted the facility to recall responses as well. Now what WOULD be neat would be INDIVIDUAL histories for commands that would pop up each time the command was invoked. My most compelling argument for keeping commands and interaction separate, though, is that I eventually want this whole dinkus to be multi-process. I want only ONE command window, but from it to be able to start up as many processes -- possibly themselves interactive -- as I wish. Any scheme that allowed me to talk to individual programs from the one command window would get pretty baroque. On the other hand, the current version of Sili(Con:) has problems here, too: interaction is through the regular DOS window in which the command output appears, so to interact you have to first click in that window; this can be awkward when, say, you want to stop output in a hurry. The next version will make the DOS window active automatically when you push the control window to the back. In the long term, I suspect the handiest solution is to have all commands that need interaction pop open their own windows for the purpose, like editors and so on do now. >............................................. In addition, at various >times ms can open scrollable output windows, completion windows, and >help windows.... > >............................................................. While >there is no way to recover lines that have scrolled out the top of the >[output] window, text can be copied from the output window into the input >window in exactly the same manner as it can be copied from the history >window. I'm not sure of the usefulness of being able to copy from output to command window, especially if my concerns about separation of function are valid. I can see it being handy to pick out file names and other arguments and splat them into commands you're building, but really there are probably only a few programs you would want to generate this sort of output (DIR for instance) and it would be better to treat these as special cases -- much as DirUtil works at the moment. So rather than allowing pick operations on the normal output window, I suggest another standardized window that could be kept available for picking from. The following may fill the bill...: > >A scrollable output window contains all the output from the last >command run. Unlike a standard output window, no output from commands >other than the last one run is available. However, all the output from >that command is available, whether it fits in the window or not. The >scroll bar needed to provide this capability is what gives this window >with its name. Since the contents of this window are destroyed with >each new command, a facility to save it for later use is provided. I like this concept. There are a few things to think about, though. Like, how does the user create one, and how long should it stay around by default? And how do you discard it? The simplest way to do the last is with a close gadget, but if we are concerned about keeping hands on the keyboard some kind of hot key would be in order. We would want some way of rotating through windows from the keyboard too, like Jim Mackraz demonstrated at the last BADGE meeting. Creation isn't hard; some kind of redirection syntax would be appropriate. Regarding its lifetime, I assume from Mike's description above he is thinking of having it stick around until the next command, but if we are talking multi-process this obviously won't do. I can suggest two options: 1) Leave it around until the user throws it away. This might get onerous. 2) Have a maximum-number-of-windows parameter (2 or 3, say) and discard on an LRU basis. If a user wanted to keep a window around longer he would lock it somehow. (It could still be closeable, but he could bring the data of a locked window back when he wanted it.) As I intimated above, I think it might be a good idea to be able to select items by mouse (and keyboard? -- how?) from scroll windows. The text has to be kept around in recoverable form anyway if you are going to scroll it, while simple output windows only need a bitmap if you otherwise don't want the fancy facilities. > >Each of the above three windows (history, output and scrollable >output) also allow the selection of sets of lines. These lines can be >copied into the input window and run as a group. If the system >supports a method for running programs to exchange data - a >"clipboard" or "system shelf" - these lines can also be copied to >that. Of course, lines can be copied from the clipboard to the input >window. What I think you're suggesting here is a "visible clipboard". Maybe we could call it a smorgasboard... [a little more variety than the usual menu...] :-) This is a valuable idea too. You would be able to pull strings out of any program's output and stash them here for use later. To me it's not so much like the clipboard, where PROGRAMS share data, as like dragging icons around on the WorkBench -- only here you're dragging strings. The programs themselves wouldn't need to know anything about it, as long as their input devices were smart. This brings the line of thought to something I think we've both been kicking around in the back of our minds: something like the Sili(Con:) window should be provided as a HANDLER, for any program to attach to if it wanted. After all, the History is a primitive form of scroll window, really (or will be when I add some scroll gadgets...). > >Completion windows provide an easy way for the user to finish typing >commands or arguments.......... >......................... The system [...] determines which words are >valid in the context of the current line, and opens a window listing >all those words. The user then clicks on the word desired,........ >........... >Help windows provide a brief description of the valid inputs in the >current context......... Again, these are great ideas, at least in principle. I have hazy doubts and questions about implementation, but I'll think on't a while. > >User Customization > >[..... Mike presents a LOT of ideas here...] I don't even want to start getting into a discussion of all the suggestions in this section. For now I'll just agree that we need a good command handling protocol; default filespace globbing by the shell is NOT what I want. I think I like the command descriptor file -- but not at floppy speed, please. (We'll soon be keeping EVERYTHING on ramdisk though, won't we?) I apologize for concentrating mostly on windows, but that's what I've been thinking about mostly myself recently. I want to let thoughts on command syntax roll around a while longer. Anyway, Mike, you've started some wheels turning in my mind [well, at least I heard the bearings creak...], so let's keep the dialog going -- and have some input from other people. -- Pete --