Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!ncar!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!kth!enea!maxim!prc
From: prc@maxim.ERBE.SE (Robert Claeson)
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Message-ID: <493@maxim.ERBE.SE>
Date: 6 Feb 89 08:42:17 GMT
References: <25@torsqnt.UUCP> <8867@bloom-beacon.MIT.EDU> <9480@smoke.BRL.MIL> <9597@smoke.BRL.MIL>
Organization: ERBE DATA AB
Lines: 38

In article <9597@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <483@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes:
> >Does this really work that good? A function key (control) character
> >sequence can be of arbitrary length. The up-arrow  key on my keyboard
> >sends three characters, whereas a typical F-key sends 5 characters.
> 
> 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.

I have already written code to parse ANSI X3.64 sequences, but since
there's so many non-ANSI terminals out there, I'm not really sure I
want to lock myself into ANSI-compatible terminals (even though I'd
like to).

> 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).

I'd like to get rid of all escape keys in the world (that's why I
only buy VT220-style keyboards nowadays), but on the other hand, I
don't think an escape key violates the standard. As I recall, all
function key sequences should start with the CSI 8-bit character
or 7-bit character sequence (ESC [) and end with an alphanumeric
character.

Oh, come to think of it, maybe I should get rid of my table-driven
code and invent "terminal handlers" instead. You know, determine
the terminal type (with ESC Z or by reading the TERM variable) and
start an appropriate process that handles all i/o to the terminal,
and have my application talk to that process (via good 'ole pipes,
message queues or shared memory).
-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
"No problems." -- Alf
Tel: +46 758-202 50  EUnet:    rclaeson@ERBE.SE  uucp:   uunet!erbe.se!rclaeson
Fax: +46 758-197 20  Internet: rclaeson@ERBE.SE  BITNET: rclaeson@ERBE.SE