peter@sugar.hackercorp.com (Peter da Silva) (01/20/91)
In article <42121@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: > I prefer the method used in CP-V, namely that the input you type ahead > does not echo until it is read. Most systems in fact do it this way. I don't like it because I find it easy and convenient to do a lot of typeahead, and I like to get immediate feedback of what I type. Cuts down on typos. Of course you could always implement a console.device that worked the way you like it... one nice thing about the Amiga is that if you don't like any part of the UI you can always change it. > Looking at a hardcopy or a screen, you > cant tell whether any given character was typed ahead or not. -- Darren I generally tell because I know what I typed. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
a218@mindlink.UUCP (Charlie Gibbs) (01/21/91)
A friend of mine has a neat little TSR on his IBM clone which
displays the typeahead buffer on the TOP line of his screen. When
he types more characters they appear at the end of the line, and
the system pulls characters from the beginning of the line as it
can accept them; the line is shifted to the left as characters are
taken out of the buffer. Carriage returns appear as some funny
character, so he can be several short command lines ahead.
It's kind of an interesting idea, at least.
Charlie_Gibbs@mindlink.UUCP
For every vision there is an equal and opposite revision.estdwha@warwick.ac.uk (CrisP) (01/21/91)
In article <1991Jan21.023415.7268@cs.umn.edu> dege@cs.umn.edu (Dege Jeffrey Charles) writes: [ Stuff other people have said about typeahead deleted. ] > > And of course, like many things on the Amiga, it has already been done. >If you mount ConMan as CNN: you get a window that allows invisible (i.e., >non-blocking) typeahead. I've tried it (and I hate it.) > Does anyone know where I can get a version of ConMan that does this. ( preferbly ftp. ) The verion I'm currently using only mentions this fature in the doc's as something for future versions. ~ CrisP. -- ------------------------------------------------- crisp@uk.ac.warwick.cs | estdwha@uk.ac.warwick.cu -------------------------------------------------
jap@convex.cl.msu.edu (Joe Porkka) (01/22/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <42121@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >> I prefer the method used in CP-V, namely that the input you type ahead >> does not echo until it is read. >Most systems in fact do it this way. I don't like it because I find it >easy and convenient to do a lot of typeahead, and I like to get immediate >feedback of what I type. Cuts down on typos. I only worked with one for a couple of minutes, but... The Appolo workstations console windows had a seperation box taking up the entire last line (sizeable perhaps?) of the console window for type ahead. Thus you get feedback, and don't interfere with normal text output. Personally I *REALLY* like the Amigas CON: behavior. The one thing missing is a way to cancel input, after hittin return, but before the shell (or whatever) reads it in. The worst is MSDOS, which ignores ctrl-s if you have typed any other characters ahead of it.
walt@bcarh133.uucp (Walt Sullivan) (01/22/91)
Bill Hawes' CONMAN (V1.3c or later) supports invisible, non-blocking type-ahead (if you open CNN: instead of CON:). It has command history, line editing, and deletion of lines that have been typed ahead, but not read! Only Amiga makes it easy! -- Walt Sullivan BITNET: walt@BNR.CA (work) UUCP: walt@orbit.amiga.OCUnix.on.ca (home)
kent@swrinde.nde.swri.edu (Kent D. Polk) (01/22/91)
In article <4510@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: > > A friend of mine has a neat little TSR on his IBM clone which >displays the typeahead buffer on the TOP line of his screen. When >he types more characters they appear at the end of the line, and >the system pulls characters from the beginning of the line as it >can accept them; the line is shifted to the left as characters are >taken out of the buffer. Carriage returns appear as some funny >character, so he can be several short command lines ahead. > > It's kind of an interesting idea, at least. I saw this first on the HP Pascal Workstations in 1983, except that it was implemented on the last line of the display and you had all of the line editing commands. This included cursor left/right, char & word delete, and insert, and had a 255 char limit, regardless of # of lines. Control characters were displayed using ascii char labels. Seems there was more, & I think I remember even hacking some of my own stuff into the type-ahead buffer routines. I know I used the other two magic areas on that last line - been too long to remember correctly. This was really incredible compared to anything else I was using at the time, especially since it was usually Intel ISIS-II Development machines (the pre-cursor to CP/M), CP/M boxes, PC's, or HP1000's. Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent
jbickers@templar.actrix.gen.nz (John Bickers) (01/23/91)
Quoted from <1991Jan21.191728.27166@msuinfo.cl.msu.edu> by jap@convex.cl.msu.edu (Joe Porkka): > The one thing missing is a way to cancel input, after hittin > return, but before the shell (or whatever) reads it in. Conman can do this. Hitting ^Z clears the typeahead buffer. Conman is a recommended CLI enhancement. So is WShell... :) > The worst is MSDOS, which ignores ctrl-s if you have typed any > other characters ahead of it. The Pause key works though. Less convenient to use on the keyboard I've got at work, but so it goes. The worst thing about MS-DOS in this respect is that the buffer is so small. One nice thing is that one can type ahead while an application is loading (due to good olde single-tasking), and have the keystrokes go to that application. Maybe not so important on the Amiga, where applications do less spawning around to fit into small amounts of memory. One can always write a script too, with ScripIt or whatever. -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
peter@sugar.hackercorp.com (Peter da Silva) (01/28/91)
In article <10640.tnews@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes: > One nice thing [about MS-DOS] is > that one can type ahead while an application is loading (due to > good olde single-tasking), and have the keystrokes go to that > application. Nothing to do with single-tasking. You can do the same thing on any system, including the Amiga, when the program doesn't explicitly flush typeahead. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jap@convex.cl.msu.edu (Joe Porkka) (01/29/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <10640.tnews@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes: >> One nice thing [about MS-DOS] is >> that one can type ahead while an application is loading (due to >> good olde single-tasking), and have the keystrokes go to that >> application. >Nothing to do with single-tasking. You can do the same thing on any system, >including the Amiga, when the program doesn't explicitly flush typeahead. Except that on the amiga, most application expect you to type into their window, which usually doesn't exist until the app is already loaded.
jbickers@templar.actrix.gen.nz (John Bickers) (01/31/91)
Quoted from <7643@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > In article <10640.tnews@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes: > > that one can type ahead while an application is loading (due to > > good olde single-tasking), and have the keystrokes go to that > > application. > Nothing to do with single-tasking. You can do the same thing on any system, > including the Amiga, when the program doesn't explicitly flush typeahead. True, it's more to do with the way input works than whether the system multitasks or not, but on the Amiga flushing typeahead has nothing to do with this problem. Suppose I start MicroEMACS from a WShell, and while it is loading from my slow HD I hit M-G124 to go to line 124... under MS-DOS these keystrokes go to MicroEMACS. On the Amiga, they go to WShell. On a single-tasking system, the input is much more likely to behave in an unshared way like MS-DOS, which is the basis of my statement above. Under programs that continued to take input from the console they were started from (ie: stayed within a single task), you'd be correct. Very few programs I use do this. This has proven to be useful in Real Life - one of the MS-DOS things I maintain has a log on screen, and users rapidly learn to enter all the keystrokes necessary to get through this screen before the screen even appears. While upgrading one of the libraries the thing uses, typeahead started getting thrown away - the users noticed and comlained quickly. > Peter da Silva. `-_-' -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
peter@sugar.hackercorp.com (Peter da Silva) (02/05/91)
In article <10856.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Suppose I start MicroEMACS from > a WShell, and while it is loading from my slow HD I hit M-G124 to > go to line 124... under MS-DOS these keystrokes go to MicroEMACS. Unless MicroEmacs opens a window of its own under DesqView or Microsoft Windows. > On the Amiga, they go to WShell. Only if you have a crummy version of MicroEmacs like the one Commodore distributes that opens its own window. > On a single-tasking system, the > input is much more likely to behave in an unshared way like MS-DOS, > which is the basis of my statement above. You mean like on the Macintosh? > Under programs that > continued to take input from the console they were started from (ie: > stayed within a single task), you'd be correct. Very few programs > I use do this. They all stay in the same task. This has, for the second time, nothing to do with multitasking. Nothing. Nada. Zip. Zero. In fact Emacs *is* still running in the shell you started from, and you can't give *it* any more commands until Emacs finishes. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jbickers@templar.actrix.gen.nz (John Bickers) (02/08/91)
Quoted from <7706@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > In article <10856.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > go to line 124... under MS-DOS these keystrokes go to MicroEMACS. > > Unless MicroEmacs opens a window of its own under DesqView or Microsoft Neither of these are "MS-DOS". Nor are they monotasking. > > On a single-tasking system, the > > input is much more likely to behave in an unshared way like MS-DOS, > > which is the basis of my statement above. > > You mean like on the Macintosh? The problem of multiple input paths is as much a GUI problem as it is a multitasking problem, so the Mac may "suffer" too. Maybe to a lesser degree. > > Under programs that > > continued to take input from the console they were started from (ie: > > stayed within a single task), you'd be correct. Very few programs > > I use do this. > > They all stay in the same task. This has, for the second time, nothing No, the ones I use do not stay in the same task. Eg: alias v = "ty [] &" alias m = "mostra [] &" alias e = "McrEMACS [] &" > to do with multitasking. Nothing. Nada. Zip. Zero. The presence of multitasking makes the problem more likely. In the specific sample set given (MS-DOS and the Amiga) this is exactly why the problem exists. Even in cases where the shell is blocked from executing commands while a program is running, it's input task (take a look in a task list at all the "CON"s, for example) is still active. > In fact Emacs *is* still running in the shell you started from, and you > can't give *it* any more commands until Emacs finishes. No, see above. And even if I _was_ the sort of person that allowed large programs to tie up my main shell, I can send the shell more commands while using MicroEMACS - they would not be executed until MicroEMACS finished, but they would not be swallowed by MicroEMACS either. > Peter da Silva. `-_-' -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***