Human vs. machine input (was: Re: Behaviour of setjmp/longjmp ...)

[JD Allen]

> None of the systems I've worked with "waste" much CPU time "watching"
> for "meaningless" transitions of the <shift> key;

This has little to do with setjmp/longjmp (or anything at all really!)
but I couldn't pass it up.

Run your favorite benchmark on the IBM PC sometime with and without the
shift key held down.  The degradation due to shift-key-depressed, as I
recall, is about 1.5 %.  (I am talking about the *original* PC with the
*original* keyboard.)  This isn't wasting "much" time, but to a
perfectionistic, waste is waste.

I'm sure the design was "justified" by the idea of making the keyboard
"soft"-programmable.  But in that case why did the ROM firmware on the
same machine handle the "Insert" and "Delete" keybuttons differently?
Auto-repeat of "Ins" is disabled, like that of "Shift" and "Ctrl"
(although not without wasting the afore-mentioned compute power),
while "Del" is treated as a "first-class" keybutton.  (Yes, I know
this asymettric treatment of Ins/Del is what the typical word processor
"wants".)

My "complaint" about the shift-key-depressed degradation has an
implicit smiley-face, but the Insert/Delete asymettry was quite
vexing to me since I took IBM at its word about "configuring your
keyboard interface to suit your fancy" and developed an application
which wanted Insert/Delete to be handled with symettry.

- James Allen

P.S.: Why did `postnews' delete `comp.lang.c' from the above Newsgroup
line?  I won't edit it back in, since the whole posting really should
be shoved into `/dev/null.'  (Or perhaps I should say "dragged into
the trashcan" since the thread was something about keyboard -vs- mouse.)