mcdonald@uxe.cso.uiuc.edu (02/08/89)
>>>> The subject being escape sequences from terminals and their
problems >>>>>>>>
The problem comes from trying to push a large round plug in a small
square hole. The keyboard I am typing this on has 101 keys (one of
which is indeed labeled 'esc'.) Lets see, 101x2 = 202 . 202 < 256.
This implies that the keyboard could send a separate key code for
when a key is pushed down, and when it is let up, and still have
room left over for an EOF indicator. In fact, it does just that.
No multicharacter sequences are necessary. The computer it is attached to
makes good use of having the complete state of the keyboard at hand.
I seriously doubt that anyone can type fast enough to overload
even a 1200 baud line. My mother can't; for many years she was the fastest
typest in Texas. Of course, I suppose somebody could sit on it :-).
The character-code only terminal isn't yet obsolete, it is just slowly
being pushed out of the way by the more complete model.les@chinet.chi.il.us (Leslie Mikesell) (02/10/89)
In article <225800122@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >>>>> The subject being escape sequences from terminals and their >problems >>>>>>>> >No multicharacter sequences are necessary. The computer it is attached to >makes good use of having the complete state of the keyboard at hand. Yes, but suppose you want to send information to a different machine. Do you send an image of the keyboard on each transition or should the the other machine maintain the state info? How are you going to send it without multibyte sequences? Why should a remote machine treat your keyboard any differently than the one connected to it (or even know the difference)? Les Mikesell
mcdonald@uxe.cso.uiuc.edu (02/11/89)
>>>>> The subject being escape sequences from terminals and their >problems >>>>>>>> >>No multicharacter sequences are necessary. The computer it is attached to >>makes good use of having the complete state of the keyboard at hand. >Yes, but suppose you want to send information to a different machine. >Do you send an image of the keyboard on each transition or should the >the other machine maintain the state info? How are you going to send >it without multibyte sequences? Why should a remote machine treat >your keyboard any differently than the one connected to it (or even >know the difference)? As long as the line can handle 2*(number_of_keys) "chars", It should be able to use the same up-and-down strokes. And, a cursory train of thought would seem to indicate that a termcap-like table driven system could be used at the far machine to make a keyboard independent interface. Do many keyboards have more than 128 keys? The remote machine SHOULDN'T have to treat remote keyboards differently. Perhaps we should begin to make a really SERIOUS distinction between direct human input and other kinds.
les@chinet.chi.il.us (Leslie Mikesell) (02/13/89)
In article <225800127@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >>>>>> The subject being escape sequences from terminals and their >>problems >>>>>>>> > >Perhaps we should begin to make a really SERIOUS distinction between >direct human input and other kinds. *DON'T EVEN THINK ABOUT THIS!* The ability to arbitrarily redirect input and output among devices/files/pipes/networks is what makes the unix toolbox approach work. Take that away and you would have a fairly useless operating system. Imagine wc working only with typed input - how often would you use it? A reasonable approach would be to make the local machine (terminal/PC or whatever) handle more operations locally and generate a standardized output stream. Personally, I don't care to waste any CPU time watching for meaningless transitions of the <shift> key. Les Mikesell