Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!ucdavis!iris!tuck
From: tuck@iris.ucdavis.edu (Devon Tuck)
Newsgroups: comp.unix.wizards
Subject: Interesting keyboard read problem (ioctl, function keys)
Message-ID: <7562@ucdavis.ucdavis.edu>
Date: 10 Aug 90 08:10:33 GMT
References: <4103@herbie.misemi> <7318@helios.TAMU.EDU>
Sender: usenet@ucdavis.ucdavis.edu
Reply-To: tuck@iris.ucdavis.edu (Devon Tuck)
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Lines: 34

Hey wizards,

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.

I am porting an editor for a bunch of users who are in deep wedlock with
their function keys, and they MUST be able to sit on their little arrow
keys and not lose any characters, BUT character throughput must be VERY
FAST.

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.

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.

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

Thanks,
	Devon Tuck
	tuck@iris.ucdavis.edu

PS - Incidentally, when I use a straight character read with VMIN>=1,
VTIME=1 the input is still too slow.