Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.programmer
Subject: Re: How do you read the arrow keys?
Message-ID: <5119:Jan107:35:3291@kramden.acf.nyu.edu>
Date: 1 Jan 91 07:35:32 GMT
References: <1990Dec28.195518.26577@ivy.uucp> <4927:Dec2920:17:4790@kramden.acf.nyu.edu> <1991Jan1.035656.27394@NCoast.ORG>
Organization: IR
Lines: 21

In article <1991Jan1.035656.27394@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes:
> As quoted from <4927:Dec2920:17:4790@kramden.acf.nyu.edu> by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> | It's really the terminal's fault, not the programmer's fault. Codes
> | coming from the terminal should be uniquely decodable as untimed byte
> | streams. In the best situation, no code is a prefix of another.
> AT&T has a very nice solution to this problem
  [ followed by fifty lines of description ]

That is not a nice solution. First of all, it's slow: most of the time
taken by at least one editor I've tested is in reading keys using a
similar method. Second, many networks will split packets at random
spots, so the method will fail every once in a while. Third, it forces
the editor to play with the terminal in ways it should not have to.
Fourth, it is a lot more complex than a simple FSA. Fifth, it introduces
time dependencies into what should be an untimed byte stream; this leads
to race conditions and serves no useful purpose.

It's the only kludge that works given our current broken terminals, but
that doesn't make it nice.

---Dan