🚀 go-pugleaf

>re: 1st Word seemingly having a bug that drops keys...

The 'problem' with 1st Word is intentional.  The first couple of versions
did simply read keypresses from the buffer, and thus when you have your
key-repeat speed set to Mach V, you could wipe out half a paragraph pretty
easily.  Same with cursor keys.  If you're half-way down the screen and you
wanted to cursor up to the top, you would hold down the cursor key for what
you figured were the appropriate number of keyclicks, but lo and behold they
were about twice as many as necessary, so you wait 30 seconds while 1st Word
scrolls up the window one line at a time.  Get the picture?  Now, when you
hold down the backspace or cursor keys, etc., you can hold them down, even
if the key is repeating a kazillion times a second, and let go _exactly_
when you've deleted or moved precisely what/where you want.  All other keys,
i.e., alphanumeric, are buffered normally.

I agree with you that this provides a somewhat awkward solution, but it is the
lesser of two evils.  Re-drawing GEM text (within windows, with clipping,
with different styles, etc.) is so slow that key repeats can always get ahead
of the screen updates.  So for dangerous or annoying things like deleting and
scrolling, GST decided to kill the buffering.

The problem is with GEM's slowness with graphics, not reading the keyboard.
So the best solution would be blindingly fast graphics.  This is my greatest
curiousity concerning the blitter.  Will it just speed up large-block animation
(i.e. the stuff of games), or will it have special instructions for blitting 
out a whole string of text at once?  Because no matter how many games you play
(or how many variations of 'Boink!' demoes you watch), you spend much more
time waiting for slo-o-ow, bit-mapped text.

				-Jonathan Fischer