grunau_b@husc4.UUCP (01/19/87)
Although my original impressions of the bundled program 1ST_WORD were that it
was an adequate, though primitive word processor, it took me no time at all
to discover that for my purposes it was quite inadequate, since it cannot come
close to keeping up with a fast typing speed. In fact, worst of all, it quite
often drops keys, which is worse than just spitting out the text long after I
have typed it.
The keys it most commonly drops are function keys of some sort: the one I
most often noticed was "RETURN" -- if you hit RETURN twice in rapid succession,
you have a 100% guarantee that 1ST_WORD will only get one of them. Similarly
if you use the CTRL-ARROW method of moving around by words instead of single
characters. If you hold down a CTRL-ARROW for repeat, you will here the key
repeating through the monitor's speaker, but 1ST_WORD will get maybe one-fourth
of the keypresses. In fact, just using non-CTRL-ed arrow will probably get you
to where you want to go faster, despite the fact that it moves only char by
char.
I assumed at first this was a function of 1ST_WORD's code -- that it was just
written inefficiently. STWRITER for instance does not suffer from this
problem. However, I began to notice that there are many cases throughout the
GEM environment where it drops keys -- in particular, a RETURN keypress.
Sometimes, it may be assumed that somebody wrote some code to flush all
pending input -- but it seems that EVERY GEM program starts with a flush of
the lookahead buffer, which seems a bit too consistent. Try changing a file
with "Show Info": you will DEFINITELY have to wait until it finishes plotting
the window before it will take your keys. I am used to typeahead, and I miss
it on this machine.
Well, I was speaking to my dealer about word processors, and told him about
how slow 1ST_WORD was, and he told me he thought that was GEM, and not that
particular program. And since then, I have definitely noticed that GEM
programs seem to accept input more slowly than .TOS programs, and in particular
that a RETURN press seems to cause an unduly large amount of processing in all
of the programs I have noticed. It could be just coincidence -- what I am
wondering is what other people might have to say about this: IS GEM unusually
slow in accepting input (or is it a fault of some lower part of the system?),
and IS it responsible for even dropping keys sometimes?
I know this is not a fault of the hardware: .TOS programs run fine, as does
MacIntosh software on the Magic Sac. MacWrite does not suffer from this
insufferable slowness and dropping of keys. If it IS a problem with GEM,
then I won't bother buying Microsoft Write, or any other GEM-based word-
processor, for that matter!
Does anybody at Atari have any comment on this? I was definitely planning on
buying Write until now, and unless I can be sure that it is not GEM that is
the culprit, I think I'll just save my money.
JJMG
{ seismo | rutgers | decvax!ihnp4 } !husc6!husc4!grunaujafischer@watrose.UUCP (01/20/87)
>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 Fischertynor@gitpyr.gatech.EDU (Steve Tynor) (01/21/87)
In article <1039@husc6.UUCP> grunau_b@husc4.UUCP (justin grunau) writes: > >close to keeping up with a fast typing speed. In fact, worst of all, it quite >often drops keys, which is worse than just spitting out the text long after I >have typed it. > >The keys it most commonly drops are function keys of some sort: the one I >most often noticed was "RETURN" -- if you hit RETURN twice in rapid succession, >you have a 100% guarantee that 1ST_WORD will only get one of them. Similarly >if you use the CTRL-ARROW method of moving around by words instead of single >characters. If you hold down a CTRL-ARROW for repeat, you will here the key etc. I'm having the same problem with the editor (an emacs/GEM hybrid). I use RawScanIn to read the command line, and often only get ~60% of what I type. VERY ANNOYING! Any ideas? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Progress means replacing something wrong with something more subtly wrong. Steve Tynor Georgia Instutute of Technology ...{akgua, allegra, amd, harpo, hplabs, ihnp4, masscomp, ut-ngp, rlgvax, sb1, uf-cgrl, unmvax, ut-sally} !gatech!gitpyr!tynor