Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!rutgers!cmcl2!phri!marob!daveh
From: daveh@marob.MASA.COM (Dave Hammond)
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Message-ID: <546@marob.MASA.COM>
Date: 8 Feb 89 01:34:28 GMT
References: <9597@smoke.BRL.MIL>
Reply-To: daveh@marob.masa.com (Dave Hammond)
Organization: ESCC  New York City
Lines: 32

In article <9597@smoke.BRL.MIL> (Doug Gwyn (VLD/VMB) <gwyn>) writes
[concerning multi-byte keystroke sequences]:
>
>The character sequence should follow ANSI X3.64, meaning that it begins
>with an ESC character and continues through an alpha.  That can be
>parsed without any timeouts at all.

Considering the number of display manufacturers *not* using ANSI X3.64
sequences, this seems a bit narrow-minded.

>What probably is contributing to the confusion is that you bought
>keyboards that have an ESC key the user can press that violates the
>X3.64 standard.  Remove the key or tell your users how to recover
>from it (treating a second consecutive ESC specially is one way).

The very "feature" which drove me away from VT-220's was the lack of
a real ESC key.  Substituting Shift-F12 (or even programming an
unshifted F-key) just doesn't cut it.  I'm sure you can think of several
programs which would break without an ESC key.

Handling keyboards which may transmit their multi-byte sequence intro
key as a single byte key is not especially difficult.  You do have to
rely on some sort of timeout, but there are adequate calls available
on most OS's to either read with timeout or peek at the keyboard queue.
Timeouts of 1/4 to 1/2 sec. on a 9600 baud serial line are adequate to
distinguish between single bytes and failed sequences -- and barely
noticeable as a "delay" to the user.

--
Dave Hammond
...!uunet!masa.com!marob!daveh
daveh@marob.masa.com