stluka@software.org (Fred Stluka) (04/10/91)
In article <1991Apr9.112142.13195@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes (as part of an ongoing diuscussion in comp.unix.questions about how to best echo typeahead, for the sake of you comp.sys.apollo guys to which I am cross-posting): > Can someone explain how Rob Pike's Plan 9 stuff does *both* echoing > immediately *and* rearranging the display so that the output doesn't > have its appearance ruined? Sounds like the best of both worlds to me .. Not exactly an answer to Ronald's question, but along the same lines... The Apollo DOMAIN systems (running Unix) have a nice solution to this. The window is divided into 2 panes with a horizontal line between them. The top pane shows the command lines you have typed intermixed with the lines of output generated, in the usual style of a Unix system on which you have done no typeahead. The bottom pane is an editor window into which you can type commands. Ordinarily the bottom pane is one line long, and when you hit return the command you typed scrolls into the top pane. However, if your previous command has not yet completed, then the new command stays in the lower pane which grows one line longer so that you can continue to enter more commands. Each time you hit return, you get another line in the bottom pane. Each time a command completes, the top line of the bottom pane scrolls into the top pane and starts being processed. You get to see all of your typeahead, as well as a clear indicator of which commands have been processed so far. Also, the resulting top window shows a natural mix of input and output, with nothing scrambled. If you get ahead of the computer to the point that there are several command lines waiting to be processed, you can scroll back up to those lines and edit them, without affecting the lines which follow. You can cause this to happen intentionally, by hitting the HOLD key to direct the computer to stop processing commands (until you hit HOLD again), if you want to compose a series of commands before allowing any of them to be processed. You can also cut and paste, from any window including the output pane, into any window including the input pane. This makes it very easy to write your own command line recall mechanism, by defining a key to search backwards through the output pane for prompts and to copying the rest of the line you choose (the command) into the input pane. Unfortunately, HP has bought Apollo, and seems to plan to drop the DOMAIN Display Manager. Hopefully, someone else will pick up on the same idea, and it will become prevalent in Unix systems. --Fred -- Fred Stluka Internet: stluka@software.org Software Productivity Consortium UUNET: ...!uunet!software!stluka 2214 Rock Hill Rd, Herndon VA 22070 USA
cudcv@warwick.ac.uk (Rob McMahon) (04/11/91)
In article <1991Apr10.141518.2135@software.org> stluka@software.org (Fred Stluka) writes: >The Apollo DOMAIN systems (running Unix) have a nice solution to this. I've used it. I *hated* it. You keep having to scan up and down between the commands you're typing and their results. That and the abysmal reaction when you enter and leave a cbreak/curses application like an editor, or less: when I leave less, I want the last thing I've been looking at to still be on the screen, thanks. Yeuch. Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
rees@dabo.citi.umich.edu (Jim Rees) (04/12/91)
In article <+G-_A&=@warwick.ac.uk>, cudcv@warwick.ac.uk (Rob McMahon) writes:
[ about the Apollo DM and its pads ]
I've used it. I *hated* it. You keep having to scan up and down between the
commands you're typing and their results. That and the abysmal reaction when
you enter and leave a cbreak/curses application like an editor, or less: when
I leave less, I want the last thing I've been looking at to still be on the
screen, thanks.
You hated it because you're still thinking of it as a vt100 emulator. DM
pads are not vt100s. If you want a vt100, start one up -- I recommend
xterm.nazgul@alphalpha.com (Kee Hinckley) (04/13/91)
In article <+G-_A&=@warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes: >I've used it. I *hated* it. You keep having to scan up and down between the >commands you're typing and their results. That and the abysmal reaction when What do you mean? The only visual difference is a small horizontal line. >you enter and leave a cbreak/curses application like an editor, or less: when >I leave less, I want the last thing I've been looking at to still be on the >screen, thanks. Have you used an xterm? They don't leave vi sessions sitting on the screen after you use them - you go back to the transcript instead. In fact most Mac terminal emulators do this too. There is the problem with pads that they don't do vt100 emulator, so they have to start a separate application for curses. So you don't see the history even if you don't clear the screen. But that's a misfeature of the particular implementation - when Apollo made pads they didn't realize that people were going to treat workstations as though they were just a way of having lots of terminals with one keyboard. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
cudcv@warwick.ac.uk (Rob McMahon) (04/13/91)
In article <50ed9956.cb12@dabo.citi.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >[ about the Apollo DM and its pads ] >You hated it because you're still thinking of it as a vt100 emulator. DM >pads are not vt100s. If you want a vt100, start one up -- I recommend xterm. But the article I was replying to was extolling the virtues of the DM pad type of interface. Okay, so I can turn it off, and make it behave like any other Unix, but that's not the point. The old ICL Perq has this same two-window approach, and I've used it under Apollo's Domain/OS (?), and under their Unix, and I think it's a pain. On a constructive note, I used to quite like the Burroughs MCP/CANDE approach of holding up output while you were half-way through an input line, allowing you to see and edit the line you were typing, and then releasing it when you hit return, until you had typed the first character of the next line. On the whole, though, with ^R, and with automatic reprint when you try to delete a character that's before a chunk of output, I prefer the Unix approach. Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
ashley@usage.csd.oz (Ashley Aitken) (04/14/91)
Talking about the DM: From article <+G-_A&=@warwick.ac.uk>, by cudcv@warwick.ac.uk (Rob McMahon): > I've used it. I *hated* it. You keep having to scan up and down between the > commands you're typing and their results. Only initially when the output pad is empty, eventually the output is just above the input pad. On the other hand, using DM you always know where you input line is, you never need to scan up and down a window, its always at the bottom in the input pad. > That and the abysmal reaction when > you enter and leave a cbreak/curses application like an editor, or less: True, the cbreak/curses application startup has a slight pause. However, it was my understanding that Apollo expected you to use their editor, and that the DM was optimized for this. In fact, I think starting a DM editor session is faster than starting vi or emacs in an xterm. > When > I leave less, I want the last thing I've been looking at to still be on the > screen, thanks. But you've got it completely wrong. DM does away completely with the need for a tool such as less (or more). If you want to scroll through (forwards, and backwards, with searching etc) a file you can just cat it (with the DM Hold function on). Even better just pop it up on the screen in another window (DM is optimized for that, remember) and scroll through it (there are even some keys especially for that!). > Yeuch. Take a closer look, and work with it for a while. It's rather tasty in fact. (Of course there is room for improvement ...) The DM is a *real* different alternative to multiple terminal sessions and it deserves a lot more consideration and attention than it gets. Chow now brown cow, Ashley Aitken. -- E-MAIL : ashley@spectrum.cs.unsw.oz.au ARNNet POSTAL : Academic Address: Residential Address: School of EE and CS, (Mech Eng Rm 447) c/o Basser College, (Flat 7A) University of New South Wales, The Kensington Colleges, Box 1,PO KENSINGTON,N.S.W.,2033. Box 24,PO KENSINGTON,N.S.W,2033. AUSTRALIA. AUSTRALIA Ph. (02) 697-5378 Fx. (02) 662-2087 Ph. (02) 663-8117
cudcv@warwick.ac.uk (Rob McMahon) (04/15/91)
In article <1991Apr12.233642.12085@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >Have you used an xterm? Yup, I use them all the time. *Our* xterms don't do that, that was the very first thing I disabled. Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
richard@aiai.ed.ac.uk (Richard Tobin) (04/17/91)
In article <-Q=_Y$_@warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes: >On a constructive note, I used to quite like the Burroughs MCP/CANDE approach >of holding up output while you were half-way through an input line, allowing >you to see and edit the line you were typing, and then releasing it when you >hit return, until you had typed the first character of the next line. This can be a pain if you've inadvertently typed something - you're left wondering where the output's gone. It's particularly annoying if you make the mistake RSX-11 made and don't release the output if the user deletes the input. It would also be good to have a way of releasing the output without hitting return or losing the input. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
barmar@think.com (Barry Margolin) (04/19/91)
In article <4497@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >In article <-Q=_Y$_@warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes: >>On a constructive note, I used to quite like the Burroughs MCP/CANDE approach >>of holding up output while you were half-way through an input line >This can be a pain if you've inadvertently typed something - you're >left wondering where the output's gone. Multics also has this option in its tty driver (actually, it's implemented in the front-end, so it doesn't work for pty's and network terminals, or when you're doing character-at-a-time I/O). It includes a timeout, so accidentally hitting a key doesn't stop output forever. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar