Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcdchg!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: Interesting keyboard read problem (ioctl, function keys)
Message-ID: <1990Aug13.211007.4990@chinet.chi.il.us>
Date: 13 Aug 90 21:10:07 GMT
References: <4103@herbie.misemi> <7318@helios.TAMU.EDU> <7562@ucdavis.ucdavis.edu>
Organization: Chinet - Public Access UNIX
Lines: 45

In article <7562@ucdavis.ucdavis.edu> tuck@iris.ucdavis.edu (Devon Tuck) writes:

>I have been working with an intersting problem...  How to write a keyboard 
>input routine that does not mess up its' transmission of repeated function
>keys.  You might have noticed that even in vi, and in the C-shell, if you
>sit on an arrow key or some other function key that maps to a character
>sequence, you get intermittent beeps, or stray characters, respectively.

>The problem is that this editor is very bulky, and spends too much time
>away from the keyboard input routine, so that if I do the logical thing
>and set VMIN=1 and VTIME=0, portions of the home key sequence (<ESC>[H),
>for example, get split across network packets and arrive with too much gap
>for the keyboard driver to consider it a valid screen movement sequence.

Doesn't look logical to me.  How about setting VMIN=1, VTIME=2 and make
your read()'s request many characters at once in order to always catch
up with the keyboard in one syscall?

>Has anyone solved this problem?  I think I might have it with a routine that
>forks on its' first call, after setting up a pipe and ioctl calls, (VMIN=0,
>VTIME=0) and thus leaves a small subprocess running alongside the editor
>acting as a slave to the keyboard and sending all characters into a pipe
>to be read at the leasure of the main character input routine.

This is a reasonable approach but shouldn't really be necessary unless you
are waiting for slow operations like a screen redraw to complete before
checking for keyboard input.  You certainly wouldn't want to set VMIN=0
though, or you will be making hundreds of syscalls/second and consume most
of the CPU.  A subprocess would want to block when there is no input since
it would have nothing else to do.  An alternative would be to make your
output routine check for input every so often.  A little math involving
chars/sec. should generate a suitable number to catch all the input
without swamping the machine.  (Use ioctl() to set O_NDELAY temporarily
so you can do a non-blocking read into a buffer). 

>How do other editors do it?  How do Crisp, emacs, etc. handle this? (as I
>mentioned, vi doesn't..)

If you don't use a bare "escape" as a command, there is no need to do any
funny timing to detect escape sequences.  If you do need the timing, the
best approach under sysV would be to let the driver do it by setting
VTIME appropriately (and you will still probably miss once in a while).

Les Mikesell
  les@chinet.chi.il.us