dmh@dicomed.UUCP (Dave Hollander) (09/16/85)
HELP:
How do you distinguish between the actual escape key and
escape sequences generated by arrow keys, etc.?
I am looking for a nice solution; however I will gratefully accept
any reasonable solution. vi running on the AT works, but it does seem to
get confused at times.
One of the keys seems to be to test to see if a key has been entered
without waiting. Is there an easy (read: section III) way to do this.
( The program runs curses on a BSD4.2 and IBM XENIX 1.0 )
Thanks in advance:
Dave Hollander
DICOMED Corp.
{ihnp4,mgnetp}!dicomed!dmhalan@drivax.UUCP (Alan Fargusson) (09/22/85)
> > HELP: > > How do you distinguish between the actual escape key and > escape sequences generated by arrow keys, etc.? > Thing is, they arn't different. What vi does is wait for a little while to see if the character following an escape is a valid 'arrow' command. It is possible to confuse vi by typing something like escape-A real fast. This is unfortunate because I tend to do exactly that when I make a mistake, backup and correct, then continue on. With my terminal type I sometimes end up on the preveous line still in insert mode. Kind of confusing. I would like to be able to change the usage of escape in vi to something else, so only the arrow keys would use escape. Anyone at Berkley listening? -- Alan Fargusson. { ihnp4, amdahl, mot }!drivax!alan
gm@trsvax (09/25/85)
There is this excellent book out from Prentice-Hall titled "Advanced
UNIX Progamming" by Marc J. Rockland. Under the chapter devoted to
signals, there is this section which talks about escape key detection:
---------------------------------------------------------------------------
There's one other common use for ALARM. Ordinarily we would consider
the scheme we are about to present too harebrained to be included in a
sober book like this one, but because it's used in the popular text editor
vi (from Berkeley), we'll describe it anyhow.
The problem this scheme solves is this: Many CRT terminals transmit an
escape sequence when a function key like HOME or END is pressed. Such a
sequence consists of the escape character followed by a series of additional
characters that indicate which key was pressed.
[describes how HOME key works...]
This is the solution adopted by vi: When an escape is read, the alarm
clock is set to one second and then a read is issued for the next character.
If read returns before the alarm goes off, it is assumed that characters
could have been transmitted that quickly only if they were generated by the
keyboard as a function key was pressed; if the alarm goes off (interrupting
read), it is assumed that the characters were typed slowly by a human--that
is, the escape itself was actually pressed.
[goes on to describe problems with this system; eg. fast typist or
a slow system could screw this scheme up.]
---------------------------------------------------------------------------
It gives a section of code which would simulate what vi does.
If you are really interested in this, you should get a copy of this book.
[The text in this note is provided by an individual and is not supported
by Tandy Corp. Because the original recording was made with analog
equipment, the high resolution of the Compact Disk can reveal limitations
of the source.]
George Moore (gm@trsvax.UUCP)oleg@birtch.UUCP (Oleg Kiselev x258) (10/01/85)
> This is the solution adopted by vi: When an escape is read, the alarm > clock is set to one second and then a read is issued for the next character. > If read returns before the alarm goes off, it is assumed that characters > could have been transmitted that quickly only if they were generated by the > keyboard as a function key was pressed; if the alarm goes off (interrupting > read), it is assumed that the characters were typed slowly by a human--that > is, the escape itself was actually pressed. > > [goes on to describe problems with this system; eg. fast typist or > a slow system could screw this scheme up.] > --------------------------------------------------------------------------- > > It gives a section of code which would simulate what vi does. > If you are really interested in this, you should get a copy of this book. > George Moore (gm@trsvax.UUCP) Oops! Don't lough, but it seems we wasted a few hours writing the same damned thing... Only we used sititimer(2) ( a 4.2 BSD call - lets you set intervals in useconds). But, seriously, there is a problem with that scheme as well -- some terminals perform HOME and some other functions on the CRT ONLY -- and don't send anything to the program... Example - HDS terminals. Or am I missing something?