EKEY in gforth in DOS 
Author Message
 EKEY in gforth in DOS

Is EKEY supposed to retun two values in succession for a key like
[up-cursor] or [home]?  Reading the standard, it seems as if it is
supposed to return a single value for "one keyboard event", not a null
on the first call to EKEY and then a character value on the second
call.

I would much prefer the events that lead to this behavior to result in
the negative of the char value that is returned, since all I need is
to have EKEY EKEY>CHAR working in a reproducible way, so that the user
can hit the extended keyboard event on the keyboard and I can use that
to write a configuration file.

(
----------
Virtually,

Bruce McFarling, Newcastle,

)



Fri, 05 Mar 2004 21:25:37 GMT  
 EKEY in gforth in DOS

Quote:

>Is EKEY supposed to retun two values in succession for a key like
>[up-cursor] or [home]?  Reading the standard, it seems as if it is
>supposed to return a single value for "one keyboard event", not a null
>on the first call to EKEY and then a character value on the second
>call.

>I would much prefer the events that lead to this behavior to result in
>the negative of the char value that is returned, since all I need is
>to have EKEY EKEY>CHAR working in a reproducible way, so that the user
>can hit the extended keyboard event on the keyboard and I can use that
>to write a configuration file.

The question is portability which is gforth's strong side.

In Unix systems you can have a full bytestream arriving over your
terminal connection after you hit a key. Annoyingly even the length
and encoding of the streams can differ between keys (see terminfo,
termcap et al.). If it would be that simple to unify all the different
terminals out there you'd become the darling of the Unix/Linux world.

But you could restrict yourself to ANSI terminals which are quite
common (at least supported via ANSI.SYS in DOS/WIN, Linux standard
terminals) or use the (n)curses library or the best: do what suits you
best.

Andreas



Fri, 05 Mar 2004 22:16:49 GMT  
 EKEY in gforth in DOS

Quote:

> In Unix systems you can have a full bytestream arriving over your
> terminal connection after you hit a key. Annoyingly even the length
> and encoding of the streams can differ between keys (see terminfo,
> termcap et al.). If it would be that simple to unify all the different
> terminals out there you'd become the darling of the Unix/Linux world.

Gforth now has ekey.fs only for vt100 keyboards. If someone volunteers
to add code for other terminals (like DOS), go ahead.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/



Fri, 05 Mar 2004 23:52:14 GMT  
 EKEY in gforth in DOS


Quote:
>Gforth now has ekey.fs only for vt100 keyboards. If someone volunteers
>to add code for other terminals (like DOS), go ahead.

Doesn't DOS ansi.sys implement ANSI esc sequences, and aren't the ANSI
esc sequences the standard version of the vt100 esc sequences?

However, there are differences between function key sequences of the
Linux console and xterm, both of which are supposed to be vt100
compatible (probably because IIRC the VT100 had no or fewer function
keys, only a keypad).

Adding a few more sequences would be no problem, though, as long as
they all are different.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Sat, 06 Mar 2004 00:10:00 GMT  
 EKEY in gforth in DOS

Quote:

> Is EKEY supposed to retun two values in succession for a key like
> [up-cursor] or [home]?  Reading the standard, it seems as if it is
> supposed to return a single value for "one keyboard event", not a null
> on the first call to EKEY and then a character value on the second
> call.

> I would much prefer the events that lead to this behavior to result in
> the negative of the char value that is returned, since all I need is
> to have EKEY EKEY>CHAR working in a reproducible way, so that the user
> can hit the extended keyboard event on the keyboard and I can use that
> to write a configuration file.

No one can tell what EKEY is supposed to return.
Is it allowed to return an address of a structure
containing more information? (The Rationale suggests that.)
If it is, for how long such values do not expire?
One ANS Forth block editor stored EKEY values into
variables during the configuratin process.
Was it really allowed by the standard?
Was it intended to allow to store and compare EKEY values?

--
too many ways, too many people making too many problems



Sat, 06 Mar 2004 05:08:48 GMT  
 EKEY in gforth in DOS

Quote:


> > Is EKEY supposed to retun two values in succession for a key like
> > [up-cursor] or [home]?  Reading the standard, it seems as if it is
> > supposed to return a single value for "one keyboard event", not a null
> > on the first call to EKEY and then a character value on the second
> > call.

> > I would much prefer the events that lead to this behavior to result in
> > the negative of the char value that is returned, since all I need is
> > to have EKEY EKEY>CHAR working in a reproducible way, so that the user
> > can hit the extended keyboard event on the keyboard and I can use that
> > to write a configuration file.

> No one can tell what EKEY is supposed to return.
> Is it allowed to return an address of a structure
> containing more information? (The Rationale suggests that.)
> If it is, for how long such values do not expire?
> One ANS Forth block editor stored EKEY values into
> variables during the configuratin process.
> Was it really allowed by the standard?
> Was it intended to allow to store and compare EKEY values?

EKEY is more of a "reserved word" than anything else.  What it returns is
"implementation defined," which means you can tell what it returns by
reading the system documentation, and there is no portable use of it, other
than via EKEY>CHAR, although even that's a little problematic.

The intent is to standardize a word for obtaining raw keyboard events, even
though it is not possible to standardize what those events look like. It can
be extremely useful on a particular platform, and provides a mechanism for
encapsulating the platform-dependent processing around handling a keyboard
event.

Cheers,
Elizabeth

--
================================================
Elizabeth D. Rather   (US & Canada)       800-55-FORTH
FORTH Inc.                                      +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
================================================



Sat, 06 Mar 2004 07:17:57 GMT  
 EKEY in gforth in DOS

Quote:

>The question is portability which is gforth's strong side.
>In Unix systems you can have a full bytestream arriving over your
>terminal connection after you hit a key. Annoyingly even the length
>and encoding of the streams can differ between keys (see terminfo,
>termcap et al.). If it would be that simple to unify all the different
>terminals out there you'd become the darling of the Unix/Linux world.

I am not asking about or for COMMON ekey values.  I am asking about
what a "keyboard event" is.  Handing over a bytestream -- rather than
an arbitrary token that says "that's keyboard even -55" -- is what
leaves me unsure whether it ought to be called EKEY.

Apperently, calling the bytestream KEYSOURCE the DOS-EKEY would be

: EKEY ( -- n )
        KEYSOURCE ?DUP 0= IF KEYSOURCE NEGATE THEN
;

and

: EKEY>CHAR ( u -- u false | char true ) DUP 0> ;

Since configuration can say, "press the up cursor key", it doesn't
matter what the value is.  But I don't see how to do a user-response
extended keyboard configuration if the EKEY provided by the
implementation does not compress extended bytestreams that might be
returned by the system into a single token.

(
----------
Virtually,

Bruce McFarling, Newcastle,

)



Sat, 06 Mar 2004 07:07:47 GMT  
 EKEY in gforth in DOS
I don't know how this fits the standard but I add
a bit to the EKEY.  I let it test a variable and if the
value is not zero invoke it as a CFA.  In this manner
I can have a "program loop" that is invoked by EKEY
instead of BEGIN-AGAIN.  Additionally, I have modified
the key code to allow it to go from application code to
interpret mode for debugging.  I like the results.
Quote:



> > > Is EKEY supposed to retun two values in succession for a key like
> > > [up-cursor] or [home]?  Reading the standard, it seems as if it is
> > > supposed to return a single value for "one keyboard event", not a null
> > > on the first call to EKEY and then a character value on the second
> > > call.

> > > I would much prefer the events that lead to this behavior to result in
> > > the negative of the char value that is returned, since all I need is
> > > to have EKEY EKEY>CHAR working in a reproducible way, so that the user
> > > can hit the extended keyboard event on the keyboard and I can use that
> > > to write a configuration file.

> > No one can tell what EKEY is supposed to return.
> > Is it allowed to return an address of a structure
> > containing more information? (The Rationale suggests that.)
> > If it is, for how long such values do not expire?
> > One ANS Forth block editor stored EKEY values into
> > variables during the configuratin process.
> > Was it really allowed by the standard?
> > Was it intended to allow to store and compare EKEY values?

> EKEY is more of a "reserved word" than anything else.  What it returns is
> "implementation defined," which means you can tell what it returns by
> reading the system documentation, and there is no portable use of it, other
> than via EKEY>CHAR, although even that's a little problematic.

> The intent is to standardize a word for obtaining raw keyboard events, even
> though it is not possible to standardize what those events look like. It can
> be extremely useful on a particular platform, and provides a mechanism for
> encapsulating the platform-dependent processing around handling a keyboard
> event.

> Cheers,
> Elizabeth

> --
> ================================================
> Elizabeth D. Rather   (US & Canada)       800-55-FORTH
> FORTH Inc.                                      +1 310-491-3356
> 5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
> Hawthorne, CA 90250
> http://www.forth.com

> "Forth-based products and Services for real-time
> applications since 1973."
> ================================================



Sat, 06 Mar 2004 07:55:25 GMT  
 EKEY in gforth in DOS
On Mon, 17 Sep 2001 23:17:57 GMT, "Elizabeth D. Rather"

Quote:

>EKEY is more of a "reserved word" than anything else.  What it returns is
>"implementation defined," which means you can tell what it returns by
>reading the system documentation, and there is no portable use of it, other
>than via EKEY>CHAR, although even that's a little problematic.
>The intent is to standardize a word for obtaining raw keyboard events, even
>though it is not possible to standardize what those events look like. It can
>be extremely useful on a particular platform, and provides a mechanism for
>encapsulating the platform-dependent processing around handling a keyboard
>event.

The question is whether EKEY should be expected to comply with its
definition, in which a "Raw Keyboard Event" is returned, according to
the definition and stack comment, as a single cell on the stack.

There's the point that may be made that not all keyboard events can be
digested into a single value on the top of the stack.

SO?  Any that can be digested in this way and delivered via EKEY
provide more portable capability than a definition of EKEY that says
"EKEY does whatever the implementor wants it to, and if you expect it
will interoperate with EKEY>CHAR, good luck (you naive sucker)."

Since without guaranteed interoperability with EKEY>CHAR there is
absolutely nothing that can be portably done with EKEY, there is
nothing lost by restricting EKEY to keyboard events that can be made
interoperable with EKEY>CHAR.  If an implementation defines KEY-EVENT
that does its current "anything goes" EKEY, and never gets around to
implementing an EKEY, at least searching for EKEY in the dictionary
will not give the false impression that a capability to translate raw
keyboard events into values on the stack is present that is in fact
absent.

"I'm sorry, this application requires the standard extension word
EKEY, which is not currently available on your system.  Consult your
system documentation to see whether this word can be made available on
your system."



Sat, 06 Mar 2004 14:14:16 GMT  
 EKEY in gforth in DOS

Quote:

> The question is whether EKEY should be expected to comply with its
> definition, in which a "Raw Keyboard Event" is returned, according to
> the definition and stack comment, as a single cell on the stack.

You think that raw keyboard events are single events from the keyboard
controller. That's wrong. PC keyboards translate extended keys (cursor
keys, function keys) into a sequence of events on the keyboard
controller. To combine those events back into raw keyboard events, the
application has to understand the keyboard protocol. Unfortunately,
ANSI.SYS doesn't change the input, only the output. Feel free to add the
patterns necessary for the event sequence provided by DOS keyboards to
ekey.fs, and send us a patch.

Remember: The DOS port for Gforth still seeks a maintainer, as noone of
the principal authors uses DOS.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/



Sat, 06 Mar 2004 16:28:18 GMT  
 EKEY in gforth in DOS


Quote:

>> The question is whether EKEY should be expected to comply with its
>> definition, in which a "Raw Keyboard Event" is returned, according to
>> the definition and stack comment, as a single cell on the stack.
>You think that raw keyboard events are single events from the keyboard
>controller.

No, I think that keyboard events are when a user hits a key.  This
then generates a sequence of events that can involve keyboard pixies
magically sending keycodes by consultation with Ye Olde Keycodes
Guide, for all I care, and then at the other end of the pipe something
pops out that can be made use of.

Quote:
> That's wrong. PC keyboards translate extended keys (cursor
>keys, function keys) into a sequence of events on the keyboard
>controller. To combine those events back into raw keyboard events, the
>application has to understand the keyboard protocol.

That's what I said.  What I said is that if it's not yet known how to
reconstruct, don't say so that such a reconstruction tool is on hand.

Quote:
>Unfortunately, ANSI.SYS doesn't change the input, only the output.
>Feel free to add the patterns necessary for the event sequence provided
>by DOS keyboards to ekey.fs, and send us a patch.

Do I understand correctly that the gforth for Linux reconstructs a
single keyboard event out of VT-102 escape sequences?

I don't know whether it is is the keyboard, the library that is being
used to compile the DOS port for gforth, or the existing EKEY, but
what the current EKEY returns is dead simple: a null, followed by a
code in the character range.  So for my purposes, where the content of
the
    ( -- u )
is not important, provided that a EKEY>CHAR can work, it would be:

: EKEY ( -- u ) EKEY ?DUP 0= IF EKEY NEGATE THEN ;

and

: EKEY>CHAR ( u -- u FALSE | c TRUE ) DUP 0> ;

I think I have ekey.fs on the floppy and over the remainder of the
week I will see if I can patch it to be less opaque than that.

I'll have to demur on maintaining, though, at least unless I get a
hard drive for the laptop ... the lack of a hard drive is why I am
running DOS gforth off a floppy in the first place.



Sat, 06 Mar 2004 18:26:30 GMT  
 EKEY in gforth in DOS

Quote:

> Do I understand correctly that the gforth for Linux reconstructs a
> single keyboard event out of VT-102 escape sequences?

Yes. EKEY maps those sequences to symbolic constants like k-left or k5
(cursor-left, function key 5). If you want to port it to DOS, you'd
catch 0 instead of #esc, and check only the next key, not a pattern, but
you should convert that key to the same symbolic constants. Check for
the "os-class" environment query, it will return the string "dos" for
DOS.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/



Sat, 06 Mar 2004 19:13:26 GMT  
 EKEY in gforth in DOS


Quote:
>Do I understand correctly that the gforth for Linux reconstructs a
>single keyboard event out of VT-102 escape sequences?

Gforth for any OS constructs keyboard events out of escape sequences.
It currently understands the sequences produced by xterm, which AFAIK
are VT100/ANSI.  If you use DOS with ansi.sys, Gforth's EKEY should
work for you, too (possibly except for function keys, because function
key sequences are apparently not standardized).

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Sat, 06 Mar 2004 20:51:20 GMT  
 EKEY in gforth in DOS

Quote:



> >Do I understand correctly that the gforth for Linux reconstructs a
> >single keyboard event out of VT-102 escape sequences?

> Gforth for any OS constructs keyboard events out of escape sequences.
> It currently understands the sequences produced by xterm, which AFAIK
> are VT100/ANSI.  If you use DOS with ansi.sys, Gforth's EKEY should
> work for you, too (possibly except for function keys, because function
> key sequences are apparently not standardized).

Here's the list (from terminal.prf) iForth for DOS recognizes.
The word =: is short for CONSTANT .

These are all two byte sequences (low byte received first)
except for the escape and backspace keys. A caret in front
of the name means the control key is pressed simultaneously.

  $4800 =: --^   $5000 =: --v
  $4B00 =: <--   $4D00 =: -->
  $7400 =: ^-->  $7300 =: ^<--
  $0008 =: BS    $0009 =: Tab
  $4700 =: Hme   $4F00 =: End
  $4900 =: PgUp  $5100 =: PgDn
  $7700 =: ^Home $7500 =: ^End
  $8400 =: ^PgUp $7600 =: ^PgDn
  $001B =: ESC   $5200 =: Ins
  $5300 =: Del   $3B00 =: F1
  $3C00 =: F2    $3D00 =: F3
  $3E00 =: F4    $3F00 =: F5
  $4000 =: F6    $4100 =: F7
  $4200 =: F8    $4300 =: F9
  $4400 =: F10
  $8500 =: F11   $8600 =: F12

-marcel



Sat, 06 Mar 2004 21:43:54 GMT  
 EKEY in gforth in DOS

Quote:
> Do I understand correctly that the gforth for Linux reconstructs a
> single keyboard event out of VT-102 escape sequences?

A side note:
IIRC a Debian update (without changing Gforth in any way) changed once
the values returned by Gforth EKEY on my Debian Linux system.
Please note the 'IIRC', my memory *might* fool me on this behalf.

I had to change my ekey mapping to get the same result as before.
i.e.   '$4012D690 CONSTANT <left>' before the update
became '$4012E690 CONSTANT <left>' after.
             ^
Same $xxxxDxxx to $xxxxExxx pattern for all the other cursor and function
keys, as far as I remember.

Robert Epprecht



Sat, 06 Mar 2004 21:54:24 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. EKEY in gforth for linux?

2. KEY , EKEY , AND EKEY>CHAR

3. CRC-32 native code for DOS GForth 0.5.0

4. Small bug in GForth.050 for DOS

5. Compiling Gforth for DOS; long

6. GForth for DOS -- HTML documentation

7. Low-Level I/O Primitives for GFORTH (for DOS)

8. Gforth, DOS and Win32 ports, Call for Volunteers

9. GForth for DOS

10. How to clear screen in Gforth Dos

11. Howto: 8M for GForth in DOS

12. gforth for MS-DOS

 

 
Powered by phpBB® Forum Software