> Yes. It's certainly not useful for programs that run on computers
> without keyboards.

KEY is not just used for keyboards! On our systems, both desktop
and embedded, KEY, EMIT and friends can be vectored on a
task/thread/callback specific basis to an i/o device, e.g. file
or serial channel.

> > IMHO it introduces
> > unspecified linkages between KEY, KEY? and ACCEPT and EKEY,
> > EKEY? and EKEY>CHAR. These linkages need to be explicit
> > (defined).

If you want to write an editor, one set of keys is for GUI
control and you might use EKEY for these. Another set is for
text, and you might use KEY for these. What are the tasking
implications when KEY and EKEY are used on the same device
channel?

If you process a key down event in your proposal, what impact if
any does it have on KEY?

> I think that demonstrates that the proposal is not tied
> to specific hardware chips.

Two PCs running Linux, both with keyboards defined around the
original 8042 implementation. Come on, hardware in these terms
is defined by chipsets, not by kilometers of separation.

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads