Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: PYGMY Forth
Message-ID: <1846.UUL1.3#5129@willett.pgh.pa.us>
Date: 12 Oct 90 00:09:16 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 27

Category 1,  Topic 45
Message 53        Thu Oct 11, 1990
JETHOMAS                     at 03:54 CDT
 
  >     I haven't understood your point, yet, in setting bit 8 instead >of bit
7, for (ONEKEY.  If you wanted to set another bit, why not >bit 15, then the
16-bit number could be checked with a 0<. But, I >don't see why you want to
distinguish between the two types of keys. >The key pressed either matches a
value in the list of OF statments >or IF statements or equivalent lists, or it
is invalid for that >operation. Maybe there are some normal keystrokes (single
byte from >DOS) that have bit 7 set, and so they become indistinguishable

  Yes, that's exactly it.  There are normal keystrokes that match.  I settled
for setting bits 7 AND 8, using bit 8 to get to SPCL in the editor, and doing
255 AND to strip out any extra bits.  By setting bit 7 too, I delayed
rewriting the SPCL' jump table in the editor. That was the only place PYGMY
used special characters.  Using bit 15 would work slightly better. I have a
prejudice for a straightforward 9-bit keyboard code, but I don't really see
that it would matter. Alt-keys are coded in increasing order from left to
right across the keyboard, apparently independent of what the key stands for.
It probably wouldn't be much advantage to code the keys as one long jump table
instead of 2 shorter ones, if it ever came to doing something like that.


-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp