nomura@meap.uta.edu (S. Nomura) (03/31/91)
I am accustomed to the type-ahead feature of the VAX/VMS. Is there any easy way to inplement this in unix ? Thank you. ----------------------------------------- Seiichi Nomura ($BLnB<Lw0l(J) Department of Mechanical Engineering nomura@meap.uta.edu University of Texas at Arlington b460nom@utarlg.bitnet Arlington, Texas 76019-0023 +1 817 273-2012 (press 2 for fax)
martin@adpplz.UUCP (Martin Golding) (04/02/91)
In <7297@utacfd.UUCP> nomura@meap.uta.edu (S. Nomura) writes: >I am accustomed to the type-ahead feature of the VAX/VMS. >Is there any easy way to inplement this in unix ? Thank you. Boy, are you running on the wrong OS. Our vendor is going to assist us in re-programming the terminal controller so we can get decent typeahead, NOBODY has had any other useful suggestions. It's worthwhile for us because we have lots of these things; otherwise your choice is pretty much to suffer in silence. Incomprehensible termio seems to be one of the techniques the gurus use to keep those obnoxious users off their machines... Martin Golding | sync, sync, sync, sank ... sunk: Dod #0236 | He who steals my code steals trash. A Poor old decrepit Pick(tm) programmer ... Sympathize at: {mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
malc@equinox.unr.edu (Malcolm Carlock) (04/02/91)
In article <659@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: -In <7297@utacfd.UUCP> nomura@meap.uta.edu (S. Nomura) writes: - ->I am accustomed to the type-ahead feature of the VAX/VMS. ->Is there any easy way to inplement this in unix ? Thank you. - -Boy, are you running on the wrong OS. Our vendor is going to assist -us in re-programming the terminal controller so we can get decent -typeahead, NOBODY has had any other useful suggestions. It's -worthwhile for us because we have lots of these things; otherwise -your choice is pretty much to suffer in silence. Huh?? What are you talking about? All the Unices I've used, since V7 on a PDP-11 to SunOS 4.1, have had decent type-ahead, so decent in fact that I've never had to worry about overrunning it. What manner of Unix are you guys running, and what applications?? Malcolm L. Carlock Internet: malc@unr.edu UUCP: unr!malc BITNET: malc@equinox Malcolm L. Carlock Internet: malc@unr.edu UUCP: unr!malc BITNET: malc@equinox
lewis@tramp.Colorado.EDU (LEWIS WILLIAM M JR) (04/03/91)
What kind of type-ahead are you talking about? All AT&T UNIX implementations support 255 character tyoe-ahead.
gwyn@smoke.brl.mil (Doug Gwyn) (04/03/91)
In article <659@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: >In <7297@utacfd.UUCP> nomura@meap.uta.edu (S. Nomura) writes: >>I am accustomed to the type-ahead feature of the VAX/VMS. >>Is there any easy way to inplement this in unix ? Thank you. >Boy, are you running on the wrong OS. ... What the hell are you guys talking about? UNIX has "always" supported type-ahead. I think what you are discussing is deferred echo. Why would you have to have that?
dik@cwi.nl (Dik T. Winter) (04/03/91)
In article <5930@tahoe.unr.edu> malc@equinox.unr.edu (Malcolm Carlock) writes: > In article <659@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: > -In <7297@utacfd.UUCP> nomura@meap.uta.edu (S. Nomura) writes: > ->I am accustomed to the type-ahead feature of the VAX/VMS. > ->Is there any easy way to inplement this in unix ? Thank you. > -Boy, are you running on the wrong OS. Our vendor is going to assist > -us in re-programming the terminal controller so we can get decent > -typeahead, NOBODY has had any other useful suggestions. It's > -worthwhile for us because we have lots of these things; otherwise > -your choice is pretty much to suffer in silence. > Huh?? What are you talking about? All the Unices I've used, since V7 > on a PDP-11 to SunOS 4.1, have had decent type-ahead, so decent in fact > that I've never had to worry about overrunning it. What manner of Unix > are you guys running, and what applications?? Enter the difference between VMS type-ahead and Unix type-ahead. Under VMS type-ahead is not echoed until it is actually needed. Unix type-ahead is echoed immediately. (This is a generalization of course and depends a bit on the Shell you are using.) I have used both and see advantages of both. 1. In VMS style type-ahead your output will never become garbled, but Unix types have a garbled view of course. 2. I prefer the Unix style when there is no output currently generated. Also some times when output *is* generated (ever attempted to kill yes hello& ?). 3. Also Unix style type-ahead has a tendency to get lost (when switching from nocbreak to cbreak etc.). The answer to the original question is: no VMS style type-ahead can not be implement given the current set of tools. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
drake@drake.almaden.ibm.com (04/03/91)
In article <15686@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >UNIX has "always" supported type-ahead. >I think what you are discussing is deferred echo. >Why would you have to have that? I think they are discussing deferred echo, too. As for why you have to have it ... well, it would sure be nice to be able to type the next command without ruining the appearance of the output of the current one! Sam Drake / IBM Almaden Research Center Internet: drake@ibm.com BITNET: DRAKE at ALMADEN Usenet: ...!uunet!ibmarc!drake Phone: (408) 927-1861
richard@aiai.ed.ac.uk (Richard Tobin) (04/03/91)
In article <15686@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >UNIX has "always" supported type-ahead. >I think what you are discussing is deferred echo. >Why would you have to have that? Good question. I find the "accidental" behaviour of shells like tcsh ideal - the characters are echoed when you type them (because the tty is in cooked mode) which makes delete (etc) usable, and again when the shell reads them (because it does its own echoing), which lets you see what commands you've executed (easily forgotten :-). -- 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
martin@adpplz.UUCP (Martin Golding) (04/04/91)
In <1991Apr2.163238.19367@colorado.edu> lewis@tramp.Colorado.EDU (LEWIS WILLIAM M JR) writes: >What kind of type-ahead are you talking about? All AT&T UNIX implementations >support 255 character tyoe-ahead. How about typeahead that doesn't echo in the middle of your output? How about typeahead that can handle change of (say) backspace AFTER the characters are typed but before they are read? How about typeahead that gets processed EVEN IF you finish typing edit commands _before_ ksh starts a read? How about typeahead for the password prompt? Oh, that kind of typeahead. What do you think this is, a B***ness system? Sorry, just one man's rants and raves... Martin Golding | sync, sync, sync, sank ... sunk: Dod #0236 | He who steals my code steals trash. A Poor old decrepit Pick(tm) programmer ... Sympathize at: {mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
martin@adpplz.UUCP (Martin Golding) (04/04/91)
In <15686@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <659@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: >>In <7297@utacfd.UUCP> nomura@meap.uta.edu (S. Nomura) writes: >>>I am accustomed to the type-ahead feature of the VAX/VMS. >>>Is there any easy way to inplement this in unix ? Thank you. >>Boy, are you running on the wrong OS. ... >What the hell are you guys talking about? >UNIX has "always" supported type-ahead. If you call it supported. If you call that typeahead. BTW ksh on my machine cannot process typedahead edit commands. >I think what you are discussing is deferred echo. >Why would you have to have that? How about, typeahead for passwords? How about, screen formatting programs? I just got out of a meeting with our vendor about this very subject- the terminal drivers are deliberately programmed against us. When you do disk stuff, the input doesn't start until the process asks: terminal stuff is crammed willy-nilly into the memory, so the controller doesn't have to be annoyed by the processes. Martin Golding | sync, sync, sync, sank ... sunk: Dod #0236 | He who steals my code steals trash. A Poor old decrepit Pick(tm) programmer ... Sympathize at: {mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
lewis@tramp.Colorado.EDU (LEWIS WILLIAM M JR) (04/05/91)
In article <3251@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: >In article <5930@tahoe.unr.edu> malc@equinox.unr.edu (Malcolm Carlock) writes: ....stuff omitted > >The answer to the original question is: no VMS style type-ahead can not be >implement given the current set of tools. My version of the korn shell (from Aspen Technologies) does both immediate and delayed echo.
gwyn@smoke.brl.mil (Doug Gwyn) (04/05/91)
In article <671@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: >If you call it supported. If you call that typeahead. Yes on both counts. >BTW ksh on my machine cannot process typedahead edit commands. Sounds like a bug in the implementation of ksh. The same feature in BRL's version of the Bourne shell does not have that problem. (The editing of course does not occur until the shell reads the characters, but they do have the desired effect at that point.) >How about, typeahead for passwords? Why do you often find yourself typing passwords? In any case, you can type them ahead, but they will be echoed. Or, you could wait until you are prompted, just in case the program ends up asking for something other than a password at that point, so you won't be embarrassed by having entered a password that ends up getting displayed. >How about, screen formatting programs? I don't know what problems you see there. >I just got out of a meeting with our vendor about this very subject- >the terminal drivers are deliberately programmed against us. When >you do disk stuff, the input doesn't start until the process asks: >terminal stuff is crammed willy-nilly into the memory, so the controller >doesn't have to be annoyed by the processes. The fundamental difference is that the data source for keyboard input is forced upon the operating system whether or not it wants it, so it must do something with that input. The disk is read only upon decision of the operating system, not of the disk. Basically I would suggest simply getting used to the UNIX input style. It is not much better or worse that what you are accustomed to, merely different.
harrison@necssd.NEC.COM (Mark Harrison) (04/06/91)
In article <5930@tahoe.unr.edu>, malc@equinox.unr.edu (Malcolm Carlock) writes: > Huh?? What are you talking about? All the Unices I've used, since V7 > on a PDP-11 to SunOS 4.1, have had decent type-ahead, so decent in fact > that I've never had to worry about overrunning it. He might be defining "decent" typeahead as not plopping characters on the screen as they are typed, but instead buffering them internally and displaying them only when they would have normally been display. Just like MS-DOS :-). -- Mark Harrison harrison@ssd.dl.nec.com (214)518-5050 {necntc, cs.utexas.edu}!necssd!harrison standard disclaimers apply...
hamilton@kickapoo.cs.iastate.edu (Jon Hamilton) (04/09/91)
drake@drake.almaden.ibm.com writes: >In article <15686@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >>UNIX has "always" supported type-ahead. >>I think what you are discussing is deferred echo. >>Why would you have to have that? >I think they are discussing deferred echo, too. As for why you have to have >it ... well, it would sure be nice to be able to type the next command >without ruining the appearance of the output of the current one! I've been waiting for someone to say this, but nobody has. tcsh does this just fine. No characters get echoed until after the ensuing prompt. This may not be true in all tcsh's, though - I've noticed that the tcsh I use under SunOS is considerably stupider than the one running under A/UX. >Sam Drake / IBM Almaden Research Center >Internet: drake@ibm.com BITNET: DRAKE at ALMADEN >Usenet: ...!uunet!ibmarc!drake Phone: (408) 927-1861 -- Jon Hamilton hamilton@kickapoo.cs.iastate.edu " I feel a lot more like I do now that I did before I got here " - can't remember who
torek@elf.ee.lbl.gov (Chris Torek) (04/09/91)
[Beware, heavy religion below... I must be feeling extra grumpy this morning.] >In article <15686@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) notes: >>UNIX has "always" supported type-ahead. >>I think what you are discussing is deferred echo. >>Why would you have to have that? In article <659@rufus.UUCP> drake@drake.almaden.ibm.com writes: >I think they are discussing deferred echo, too. (Doug already said that....) >As for why you have to have it ... well, it would sure be nice to be >able to type the next command without ruining the appearance of the >output of the current one! True ... but deferred echo is not the way to do this. Deferred echo is even more broken than immediate echo. The *only* right thing is immediate-echo-unless-it-would-not-be-echoed-when-read followed by drag-user-echo-along-in-front-of-output. That is, if you type % compute _ (here the underscore represents the cursor position) and compute runs for two minutes, then prints an answer, and you type `compute2<RETURN>' in the meantime, the screen should show: % compute compute2 _ When `compute' finishes the screen should look like this: % compute The answer is 42. % compute2 _ If, on the other hand, you type % compute and compute runs for two minutes, then demands a password, and while it is running you type `mypassword<RETURN>', `mypassword' (and possibly the RETURN) should *not* appear on the screen. Both of these are far too much work for me to want them done in a `tty driver' (or `streams module' or ANYthing in the kernel), so even though these are both required to make typeahead echo truly work, I am just as happy that typeahead echo does not `truly work'. As such, I much prefer immediate echo (and if I used VMS, and were therefore limited to VAXen ---which are, these days, horrendously slow---I would *really* hate waiting for the computer just so I could see if I made any typos). Now, if I had a GNOT, I would get `sliding echo-ahead' `for free', which solves most of the problem---password typeahead is very rare and `do not echo if future events would cause this not to be echoed' is an unreasonable demand. Or I could use Emacs, which almost gets it right (Emacs does not get an `input taken' message and therefore cannot know when to stop sliding typeahead; it uses a completely different trick). The reason this can be done on the GNOT is that the GNOT knows it is a GNOT, and in this case the `terminal' is part of the whole O/S. I do not want to make the VMS mistake of assuming everything is a (VT100, Wyse, pick-some-favorite-brand), therefore I do not want screen control in my kernel. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
ronald@robobar.co.uk (Ronald S H Khoo) (04/09/91)
drake@drake.almaden.ibm.com writes: > In article <15686@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > >UNIX has "always" supported type-ahead. > >I think what you are discussing is deferred echo. > > I think they are discussing deferred echo, too. As for why you have to have > it ... well, it would sure be nice to be able to type the next command > without ruining the appearance of the output of the current one! 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 .. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
gwyn@smoke.brl.mil (Doug Gwyn) (04/10/91)
In article <1991Apr9.112142.13195@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >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 .. Presumably it uses much the same scheme as his "mux" (Blit layers multiplexer/terminal emulator). There is an "insertion point" in the stream of characters (including embedded newlines) in a display; anything "behind" the insertion point can be freely edited, and ditto for anything in front of the insertion point, with the special feature that insertion of a newline in front of the insertion point causes everything from the insertion point through the newline to be sent to the underlying process (for "mux", this would be to the UNIX process trying to read input from the layer). All that has to occur to preserve the text after the insertion point is for fresh output to be placed into the display AT the insertion point. Simple?
gwyn@smoke.brl.mil (Doug Gwyn) (04/10/91)
In article <15783@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >... insertion of a newline in front of the insertion point causes >everything from the insertion point through the newline to be sent >to the underlying process ... I forgot to mention that this also moves the insertion point to just after the newline.
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
richard@aiai.ed.ac.uk (Richard Tobin) (04/11/91)
In article <15784@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >I forgot to mention that this also moves the insertion point to just >after the newline. Presumably this happens when the process reads the line, rather than when the newline is inserted? -- 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
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
sja@sirius.hut.fi (Sakari Jalovaara) (04/15/91)
>>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. Well... That depends. I've set up xterm so that it doesn't lose what it was showing. All you need is a suitable termcap entry; those who like it the other way can set their TERM to xterm-2p (2p for 2 pages; some BSD documentation recommends this naming convention): vs|xterm|vs100|xterm terminal emulator (X window system):\ [... usual xterm entry except te and ti entries removed ...] vs-2p|xterm-2p|vs100-2p|xterm terminal emulator (with two screens) (X window system):\ :te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:tc=xterm Matter of taste. ++sja
alex@am.sublink.org (Alex Martelli) (04/16/91)
torek@elf.ee.lbl.gov (Chris Torek) writes:
...
:True ... but deferred echo is not the way to do this. Deferred echo
:is even more broken than immediate echo. The *only* right thing is
:immediate-echo-unless-it-would-not-be-echoed-when-read followed by
:drag-user-echo-along-in-front-of-output. That is, if you type
...
:Now, if I had a GNOT, I would get `sliding echo-ahead' `for free',
:which solves most of the problem---password typeahead is very rare and
:`do not echo if future events would cause this not to be echoed' is an
:unreasonable demand. Or I could use Emacs, which almost gets it right
An IBM 3270 under VM/CMS almost "gets it right", too, most of the time:
the bottom two lines are used as an 'input pad' where you can (locally,
in the terminal/controller) edit one logical-line worth of "future
input" (with echo) - however, when you "Enter" this input, it goes to
the system, which 'stacks' it (without re-echoing it until it is
asked for - and the application can choose to explicitly 'flush' and
reject typed-ahead lines). The editing capability of the terminal and
controller is really too limited, one line is far too little, etc, but
I believe the "separate input pad" approach was later adopted and
generalized in Apollo workstations. I wouldn't mind, for many apps,
a variation of xterm that would give me a separate "input preparation"
text-editing widget (I know, I know, I can almost fake it with
xclipboard or whatever, and using selections, but...).
Yup, I know, GNOTs are far more elegant, but I surmise there are more
Apollos, X servers, and 3270s around (probably in increasing order of
abundance?) than GNOTs...
--
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).gwyn@smoke.brl.mil (Doug Gwyn) (04/16/91)
In article <4467@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >In article <15784@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >>I forgot to mention that this also moves the insertion point to just >>after the newline. >Presumably this happens when the process reads the line, rather than when >the newline is inserted? That I don't recall, but my guess would be not, since the interface has no idea when the input data will actually be consumed by a process on the host. In an independent reimplementation of the basic notion, you could opt to do this whatever way seems suitable. Let us know how it turns out.
gwyn@smoke.brl.mil (Doug Gwyn) (04/16/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. Yes, but one problem we had with that was that a partial input (say, a space character) would block output indefinitely, which could be bad news if urgent messages were piling up. >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. Not all flavors of UNIX implement those features, which are typical of a "BSD-style" terminal handler. Recently, such features have been creeping into AT&T UNIX System V-based implementations. However, not all of them are done right. We have serious problems, for example, with the BSD-style terminal handler on SGI Irix 3.3.1 when used with DC3/DC1 flow-controlling terminals and various screen editors (also, ^V in such a mode sometimes is taken as a literal ^V character and sometimes causes a "literal-next" of the following character). The history of such features has shown that it is hard to get them to ALL work together correctly.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/16/91)
In article <15845@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > The history of such features has shown that it > is hard to get them to ALL work together correctly. You should try Ultrix 4.1. Sure, DEC made some big mistakes in that OS (like the way you can spawn /bin/login and trash the host field in your utmp entry, even the user field if you know what you're doing), and some of the standard applications do dumb things like leaving your tty in POSIX mode, but the kernel tty user interface works amazingly well. The part I'm most impressed by is the way that characters are preserved when you switch from cbreak to cooked mode: I simply can't tell when the switch happened, because any typeahead is echoed properly and stuck back into the cooked cbuf so that line editing works. It's years ahead of the latest releases from Convex and Sun, not to mention 4.3-Reno. ---Dan
torek@elf.ee.lbl.gov (Chris Torek) (04/17/91)
In article <17309:Apr1614:19:5491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >... The part I'm most impressed by is the way that characters are >preserved when you switch from cbreak to cooked mode [in Ultrix 4.1]: >I simply can't tell when the switch happened, because any typeahead >is echoed properly and stuck back into the cooked cbuf so that line >editing works. (This is the right thing to do; it is also impossible in the `streams' stuff in current SunOS releases, because the ldterm module may not pull data back down from the streams head. There are only two fixes: allow data to be retracted, or do not send data upstream until it is requested.) >It's years ahead of the latest releases from Convex and Sun, Sun, at least, for the reason given above; but: >not to mention 4.3-Reno. huh? 4.3BSD (all releases thereof) have always done this. What do you think the PENDIN and catq() under TIOCSETA{,W} are doing in tty.c? -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/17/91)
In article <12132@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: > >not to mention 4.3-Reno. > huh? 4.3BSD (all releases thereof) have always done this. What do > you think the PENDIN and catq() under TIOCSETA{,W} are doing in tty.c? I haven't looked at the tty code. However, under an almost straight BSD 4.3 system, output is not echoed or returned to the cooked buffer, and it wouldn't matter anyway since all the applications use TIOCSETP. In fact, under your BSD 4.3++ (ahem), output is not re-echoed, ^M is not converted back to ^J, and line editing does not work upon the typeahead. I just tried it today, so don't tell me things work. ---Dan
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
torek@elf.ee.lbl.gov (Chris Torek) (04/17/91)
In article <28216:Apr1700:51:4791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In fact, under your BSD 4.3++ (ahem), output is not re-echoed, (output? you mean typeahead? output certainly should not be reprinted.) In most cases, typeahead should not be reprinted either (only if it was `typed ahead' while echo was off). Right now PENDIN is not always set when it should be (mainly because it is `too hard' to tell when it should be). >^M is not converted back to ^J, Hm. This is more troublesome: conversion is a one-way street. Once input characters have been translated (e.g., ^V applied, ^C translated to SIGINT, etc), there is no going back. I am not entirely sure it is right to do all this just because one non-ICANON-program exited before another is about to start. >and line editing does not work upon the typeahead. >I just tried it today, so don't tell me things work. I just tried that yesterday and it *did* work. (It even let me back up over newline, which is a bit odd.) That is: stty -icanon; sleep 5; echo going back; stty icanon; sleep 5 and type several lines; after `going back' you can edit the typeahead. But (as noted above) unconverted stuff is not converted; if you typed ^H while ICANON was clear, you have, in effect, typed ^V^H as far as the ICANON-mode code is concerned. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
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
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/19/91)
In article <1991Apr15.220135.391@am.sublink.org> alex@am.sublink.org (Alex Martelli) writes: > An IBM 3270 under VM/CMS almost "gets it right", too, most of the time: > the bottom two lines are used as an 'input pad' where you can (locally, > in the terminal/controller) edit one logical-line worth of "future > input" (with echo) - however, when you "Enter" this input, it goes to > the system, which 'stacks' it Note that my ``pmlined'' for UNIX implements the same style of line input. It uses the status line of your terminal (with a _ cursor), uses polite left-to-right scrolling, allows various control characters for history editing, etc. It's not particularly well coded, and it's not particularly efficient, but it works if you set up your tty modes right. Oh, yeah, you can also toggle the extra layer with ^A. I'll post an updated version of pmlined to alt.sources, including Gnot-style editing (based on Chris's and Doug's comments) and arrow key input, in the next few days. The old version is available from stealth.acf.nyu.edu if you're absolutely desperate. ---Dan
luo@algol.cs.umbc.edu (Hong Luo) (04/25/91)
-- TEST
luo@algol.cs.umbc.edu (Hong Luo) (04/25/91)
TEST -- TEST