Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.sys.amiga Subject: Re: Proposal for an Amiga Shell Message-ID: <2445@jade.BERKELEY.EDU> Date: Thu, 5-Feb-87 03:47:00 EST Article-I.D.: jade.2445 Posted: Thu Feb 5 03:47:00 1987 Date-Received: Sat, 7-Feb-87 11:12:04 EST References: <2444@jade.BERKELEY.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) Distribution: net Organization: Missionaria Phonibalonica Lines: 100 Keywords: Amiga shell CLI Sili(Con:) windows In article <2444@jade.BERKELEY.EDU> pete@topaz.berkeley.edu.UUCP (Pete Goodeve) writes: >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 thought about it, and decided I liked having a seperate input & history window, with the history window normally hidden, and a hot-key/menu-click/whatever to get to it. However, the Apollo system also sounds nice; two panes, with all unconsumed input being shown in the "input" pane. >I used "command" rather than "input" window because I feel strongly that >[command input should be separated from commands - paraphrased, mwm.] One of the things that annoys me most about csh history is that it doesn't include input to commands, even some of its own builtins. After using ksh (which did these things right), csh is a pain. Having input to other commands in the same stream is also nice. Of course, if something starts it's own dialog window (more, emacs, vt100, whatever) then it should be left strictly alone. >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. It's nice - when you need it. To hold the expense down, you only keep lines that are visible. Shouldn't be to bad (remember, we're talking about a machine with a meg or more of memory!). >[scrollable output windows] >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? Left purposely vague. The idea was that the window would be there, "undisplayed" for the last command. You can then ask for it to be displayed, do something to "freeze" it, then later close that window. Unless you freeze it, the next command will cause it to go away. >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...). Yes! I've looked into providing a "history" for Unix that works sorta like the script command, so you can get to all of your input back. I know someone who started on this. Of course Xterm and the Suntools console window both have this feature. But you want it for EVERY window that has a line-oriented CON: device. Maybe a "HISTORY:", thats identical to the CON: device, but it lets you pick things up from the display and put them onto a clipboard. With a normal font, even on an interlaced screen, this would take 50x80 or 4K. Not a bad price for that ability... >>User Customization >> >>[..... Mike presents a LOT of ideas here...] As usual, lifted from _lots_ of different places. >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?) Well, not on ramdisk. I was thinking about keeping it in an internal tree or hash table (have to look into the problem of command completion - can I do it with a hash table?), with a csh-like "rehash" command. We do seem to have a difference in feel for what a command processor should be. You want it to be a tool for managing multiple processes, etc. I want it to be a tool for dealing with a sequential string of processes. If I need more than one such string, I'll start a new one. Both points have their advantages, and I truly loved MASTER on my old TOPS-10 systems. But I'm not sure that such a thing on top of intuition is such a good idea. Then again, you don't have to worry about split history lists, etc.... >I apologize for concentrating mostly on windows, but that's what I've been >thinking about mostly myself recently. Ah, but that's the interesting part if you've got an Amiga. The second half can be done on a MS-DOS machine, or some large VAX. Not nearly as much fun. If you're interested, that paper has been rescribled to reflect some of the early comments (the user customization part was actually simplified because of some of your suggestions. Thanx, guys!), and shipped off to SIGSMall/SIGPC. Cheers,