Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #55002 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2017-02-19 02:52 -0800 |
| Last post | 2017-03-12 00:36 +0000 |
| Articles | 20 on this page of 45 — 12 participants |
Back to article view | Back to comp.lang.forth
Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-19 02:52 -0800
Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-21 17:16 -0500
Re: Inconsequent EKEY values in GForth Julian Fondren <julian.fondren@gmail.com> - 2017-02-21 14:26 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-21 23:01 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-21 23:50 -0800
Re: Inconsequent EKEY values in GForth Paul Rubin <no.email@nospam.invalid> - 2017-02-22 00:40 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 00:44 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 00:48 -0800
Re: Inconsequent EKEY values in GForth Paul Rubin <no.email@nospam.invalid> - 2017-02-22 00:51 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 00:54 -0800
Re: Inconsequent EKEY values in GForth minforth@arcor.de - 2017-02-22 02:11 -0800
Re: Inconsequent EKEY values in GForth Paul Rubin <no.email@nospam.invalid> - 2017-02-22 13:46 -0800
Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-22 17:04 -0500
Re: Inconsequent EKEY values in GForth minforth@arcor.de - 2017-02-23 04:21 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-23 05:51 -0800
Re: Inconsequent EKEY values in GForth Julian Fondren <ayrnieu@gmail.com> - 2017-02-23 06:02 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-23 06:10 -0800
Re: Inconsequent EKEY values in GForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-23 15:45 +0000
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-23 07:07 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 04:25 -0800
Re: Inconsequent EKEY values in GForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-22 14:22 +0100
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 11:16 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 11:44 -0800
Re: Inconsequent EKEY values in GForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-23 16:21 +0000
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-24 05:04 -0800
Re: Inconsequent EKEY values in GForth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-24 12:27 -1000
Re: Inconsequent EKEY values in GForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-25 12:51 +0100
Re: Inconsequent EKEY values in GForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-25 16:37 +0000
Re: Inconsequent EKEY values in GForth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-03-12 04:20 +0000
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-25 05:14 -0800
Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-25 16:24 -0500
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-25 18:48 -0800
Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-25 23:41 -0500
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-26 00:48 -0800
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-26 03:13 -0800
Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-26 15:27 -0500
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-26 23:39 -0800
Re: Inconsequent EKEY values in GForth peter.m.falth@gmail.com - 2017-02-26 14:42 -0800
Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-26 18:20 -0500
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-26 23:43 -0800
Re: Inconsequent EKEY values in GForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-27 13:03 +0100
Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-27 04:22 -0800
Re: Inconsequent EKEY values in GForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-27 13:31 +0100
Re: Inconsequent EKEY values in GForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-23 16:27 +0000
Re: Inconsequent EKEY values in GForth Bernd Paysan <bernd@net2o.de> - 2017-03-12 00:36 +0000
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-02-22 14:22 +0100 |
| Message-ID | <o8k3bc$lpl$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #55054 |
In article <e0e5d02b-0d38-49a7-8a11-d1c5615ee689@googlegroups.com>,
lehs <skydda.barnen@gmail.com> wrote:
>There is an other problem with EKEY in GForth:
>
>32-bit Windows makes no difference of e.g. 'right arrow' and 'ctrl right arrow'. Bad, since 'ctrl right arrow' is used for 'next word'.
>
>64-bit Windows makes a bad difference, since 'ctrl right arrow' gives one number on the stack and emit the code '[1;5C', making it totally impossible in my editor.
Ideally for editors a Forth should make
shift up
shift down
ctrl up
ctrl down
alt up
alt down
mouse button1 up
mouse button1 down
mouse buttonx up
..
into separate EKEY events, and remember the time of the last EKEY
event.
In this way an editor can differentiate between
a double click on a word with the shift pressed, and without.
And at last I can get into caps lock mode by double "clicking" the
shift key and free the caps lock key (to become a control key).
An editor is a real time program. Every attempt to make the ideal
editor without that in mind is futile.
And of course the edit commands should be collected in a commands
wordlist, like so:
---------------------------------
\ Put a printable char into the buffer and onto the screen.
: SEMIT ... ;
wordlist CONSTANT commands
CREATE command 100 ALLOT
: clear-command "" command $! ;
\ process a key to build up a sequence that is a command.
: process command $C+
command $@ commands SEARCH-WORDLIST IF EXECUTE clear-command THEN
set-time-out ;
: edit clear-command
BEGIN EKEY glyph? IF SEMIT ELSE process THEN stop? UNTIL ;
\ To add a command example.
CURRENT @ commands CURRENT !
\ add a
: latest delete-line-in-buffer delete-line-on-screen ;
clear-command ctl Y command $C+
command $@ $, 'latest >NFA ! \ change the name of `latest
CURRENT !
\ A separate process takes care of the time-out.
\ If the user doesn't type a character for say one second
\ it is checked whether the content of `command could be expanded
\ to a valid key sequence. If not a notification follows and the
\ command buffer is cleared. (Or always notify after 1 second.)
---------------------------------
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-22 11:16 -0800 |
| Message-ID | <2356a6f3-af87-4d5f-8d84-675486d95459@googlegroups.com> |
| In reply to | #55056 |
Den onsdag 22 februari 2017 kl. 14:22:42 UTC+1 skrev Albert van der Horst: > In article <e0e5d02b-0d38-49a7-8a11-d1c5615ee689@googlegroups.com>, > lehs <skydda.barnen@gmail.com> wrote: > >There is an other problem with EKEY in GForth: > > > >32-bit Windows makes no difference of e.g. 'right arrow' and 'ctrl right arrow'. Bad, since 'ctrl right arrow' is used for 'next word'. > > > >64-bit Windows makes a bad difference, since 'ctrl right arrow' gives one number on the stack and emit the code '[1;5C', making it totally impossible in my editor. > > Ideally for editors a Forth should make > shift up > shift down > ctrl up > ctrl down > alt up > alt down > mouse button1 up > mouse button1 down > mouse buttonx up > .. > into separate EKEY events, and remember the time of the last EKEY > event. > > In this way an editor can differentiate between > a double click on a word with the shift pressed, and without. > > And at last I can get into caps lock mode by double "clicking" the > shift key and free the caps lock key (to become a control key). > > An editor is a real time program. Every attempt to make the ideal > editor without that in mind is futile. > > And of course the edit commands should be collected in a commands > wordlist, like so: > > --------------------------------- > \ Put a printable char into the buffer and onto the screen. > : SEMIT ... ; > > wordlist CONSTANT commands > CREATE command 100 ALLOT > : clear-command "" command $! ; > \ process a key to build up a sequence that is a command. > : process command $C+ > command $@ commands SEARCH-WORDLIST IF EXECUTE clear-command THEN > set-time-out ; > > : edit clear-command > BEGIN EKEY glyph? IF SEMIT ELSE process THEN stop? UNTIL ; > > \ To add a command example. > CURRENT @ commands CURRENT ! > \ add a > : latest delete-line-in-buffer delete-line-on-screen ; > clear-command ctl Y command $C+ > command $@ $, 'latest >NFA ! \ change the name of `latest > CURRENT ! > > \ A separate process takes care of the time-out. > \ If the user doesn't type a character for say one second > \ it is checked whether the content of `command could be expanded > \ to a valid key sequence. If not a notification follows and the > \ command buffer is cleared. (Or always notify after 1 second.) > --------------------------------- > > > Groetjes Albert > -- > Albert van der Horst, UTRECHT,THE NETHERLANDS > Economic growth -- being exponential -- ultimately falters. > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst This seems to be really good advises, Albert. Sooner or later I will involve this thoughts in the growing editor, but for the moment I like to keep it as simple as possible.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-22 11:44 -0800 |
| Message-ID | <31a7e880-cbd2-4fdf-af30-4bf08f743f93@googlegroups.com> |
| In reply to | #55054 |
Den onsdag 22 februari 2017 kl. 13:25:17 UTC+1 skrev lehs: > There is an other problem with EKEY in GForth: > > 32-bit Windows makes no difference of e.g. 'right arrow' and 'ctrl right arrow'. Bad, since 'ctrl right arrow' is used for 'next word'. > > 64-bit Windows makes a bad difference, since 'ctrl right arrow' gives one number on the stack and emit the code '[1;5C', making it totally impossible in my editor. This is not correct for 64-bit GForth for Windows! I must have mixed up EKEY with key...? EKEY don't emit an escape code when combining ctrl with other keys.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-23 16:21 +0000 |
| Message-ID | <2017Feb23.172120@mips.complang.tuwien.ac.at> |
| In reply to | #55054 |
lehs <skydda.barnen@gmail.com> writes:
>64-bit Windows makes a bad difference, since 'ctrl right arrow' gives one number on the stack and emit the code '[1;5C', making it totally impossible in my editor.
Actually, <ESC>[1;5C is known to Gforth's EKEY as 'ctrl right arrow',
and you get the appropriate code. For 32-bit Windows, you can try if
you can set up the terminal so that it makes a difference between
'right arrow' and 'ctrl right arrow', but in general, I recommend that
you provide another way to get at the functionality in addition to the
special key combination that may not be available everywhere.
- 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
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-24 05:04 -0800 |
| Message-ID | <d72e2a32-0e86-450b-858a-7f93c4c8bb37@googlegroups.com> |
| In reply to | #55071 |
Den torsdag 23 februari 2017 kl. 17:27:13 UTC+1 skrev Anton Ertl: > lehs <skydda.barnen@gmail.com> writes: > >64-bit Windows makes a bad difference, since 'ctrl right arrow' gives one number on the stack and emit the code '[1;5C', making it totally impossible in my editor. > > Actually, <ESC>[1;5C is known to Gforth's EKEY as 'ctrl right arrow', > and you get the appropriate code. For 32-bit Windows, you can try if > you can set up the terminal so that it makes a difference between > 'right arrow' and 'ctrl right arrow', but in general, I recommend that > you provide another way to get at the functionality in addition to the > special key combination that may not be available everywhere. > > - 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 > New standard: http://www.forth200x.org/forth200x.html > EuroForth 2016: http://www.euroforth.org/ef16/ From DPANS94 ANS Forth: "A.10.6.2.1305 EKEY EKEY provides a standard word to access a system-dependent set of raw keyboard events, including events corresponding to members of the standard character set, events corresponding to other members of the implementation-defined character set, and keystrokes that do not correspond to members of the character set. EKEY assumes no particular numerical correspondence between particular event code values and the values representing standard characters. On some systems, this may allow two separate keys that correspond to the same standard character to be distinguished from one another." I interpret this as that EKEY should return raw code from each key on a keyboard without special interpretation.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-02-24 12:27 -1000 |
| Message-ID | <OO-dnXKKk_PDLi3FnZ2dnUU7-XGdnZ2d@supernews.com> |
| In reply to | #55080 |
On 2/24/17 3:04 AM, lehs wrote: > Den torsdag 23 februari 2017 kl. 17:27:13 UTC+1 skrev Anton Ertl: >> lehs <skydda.barnen@gmail.com> writes: >>> 64-bit Windows makes a bad difference, since 'ctrl right arrow' gives one number on the stack and emit the code '[1;5C', making it totally impossible in my editor. >> >> Actually, <ESC>[1;5C is known to Gforth's EKEY as 'ctrl right arrow', >> and you get the appropriate code. For 32-bit Windows, you can try if >> you can set up the terminal so that it makes a difference between >> 'right arrow' and 'ctrl right arrow', but in general, I recommend that >> you provide another way to get at the functionality in addition to the >> special key combination that may not be available everywhere. >> >> - 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 >> New standard: http://www.forth200x.org/forth200x.html >> EuroForth 2016: http://www.euroforth.org/ef16/ > > From DPANS94 ANS Forth: > > "A.10.6.2.1305 EKEY > EKEY provides a standard word to access a system-dependent set of raw keyboard events, including events corresponding to members of the standard character set, events corresponding to other members of the implementation-defined character set, and keystrokes that do not correspond to members of the character set. > > EKEY assumes no particular numerical correspondence between particular event code values and the values representing standard characters. On some systems, this may allow two separate keys that correspond to the same standard character to be distinguished from one another." > > I interpret this as that EKEY should return raw code from each key on a keyboard without special interpretation. > Yes, that was the intent. We recognize that some OSs don't make actual key codes available, but that's their problem. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-02-25 12:51 +0100 |
| Message-ID | <o8rr39$m7h$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #55084 |
In article <OO-dnXKKk_PDLi3FnZ2dnUU7-XGdnZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: >On 2/24/17 3:04 AM, lehs wrote: >> Den torsdag 23 februari 2017 kl. 17:27:13 UTC+1 skrev Anton Ertl: >>> lehs <skydda.barnen@gmail.com> writes: >>>> 64-bit Windows makes a bad difference, since 'ctrl right arrow' gives one number on the stack and emit the code '[1;5C', making it totally impossible in my editor. >>> >>> Actually, <ESC>[1;5C is known to Gforth's EKEY as 'ctrl right arrow', >>> and you get the appropriate code. For 32-bit Windows, you can try if >>> you can set up the terminal so that it makes a difference between >>> 'right arrow' and 'ctrl right arrow', but in general, I recommend that >>> you provide another way to get at the functionality in addition to the >>> special key combination that may not be available everywhere. >>> >>> - 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 >>> New standard: http://www.forth200x.org/forth200x.html >>> EuroForth 2016: http://www.euroforth.org/ef16/ >> >> From DPANS94 ANS Forth: >> >> "A.10.6.2.1305 EKEY >> EKEY provides a standard word to access a system-dependent set of raw keyboard events, including events corresponding to members of the standard character set, events corresponding to other members of the implementation-defined character set, and keystrokes that do not correspond to members of the character set. >> >> EKEY assumes no particular numerical correspondence between particular event code values and the values representing standard characters. On some systems, this may allow two separate keys that correspond to the same standard character to be distinguished from one another." >> >> I interpret this as that EKEY should return raw code from each key on a keyboard without special interpretation. >> > >Yes, that was the intent. We recognize that some OSs don't make actual >key codes available, but that's their problem. Not surprisingly, that is also easier than groping through to the bottom of a pile of leaky abstractions. E.g. the key handling of colorforth is relatively simple. There is not reason why Linux couldn't supply a raw /dev/keyboard device, maybe it even does. > >Cheers, >Elizabeth Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-25 16:37 +0000 |
| Message-ID | <2017Feb25.173757@mips.complang.tuwien.ac.at> |
| In reply to | #55080 |
lehs <skydda.barnen@gmail.com> writes:
>From DPANS94 ANS Forth:
>
>"A.10.6.2.1305 EKEY
>EKEY provides a standard word to access a system-dependent set of raw keybo=
>ard events, including events corresponding to members of the standard chara=
>cter set, events corresponding to other members of the implementation-defin=
>ed character set, and keystrokes that do not correspond to members of the c=
>haracter set.
>
>EKEY assumes no particular numerical correspondence between particular even=
>t code values and the values representing standard characters. On some syst=
>ems, this may allow two separate keys that correspond to the same standard =
>character to be distinguished from one another."
>
>I interpret this as that EKEY should return raw code from each key on a key=
>board without special interpretation.
That interpretation does not fit well with K-CTRL-MASK, K-ALT-MASK,
K-SHIFT-MASK. A certain amount of preprocessing is quite useful and
convenient in most cases. If you want less, you can use OS-specific
or hardware-specific ways to get at the events.
In particular, for a Forth system that talks to a terminal (or
terminal emulator), the terminal tends to produce an escape sequence
when you press a cursor or other special key; there is usually no way
to get at the raw keycodes that are internal to the terminal. Also
the terminal or the OS do stuff like flow-control by default (and use
Ctrl-S/Ctrl-Q for that by default), and interpret e.g., Ctrl-C and
Ctrl-Z as signals by default.
It would also not be helpful for EKEY to wait for a keypress on the
console of the machine on which the Forth system runs, because the
user can be at a completely different keyboard; the machine running
the Forth system may actually not have a keyboard at all (e.g., the
Odroid C2 computer I use for Aarch64 development has no keyboard).
For a Forth system that works as an X application (such as xbigforth),
EKEY could provide X events; this at least gives network transparency,
but still has the disadvantage that the application would have to deal
with KeyPress, KeyRelease, MotionNotify and other events; this may be
what the application wants, but relying on that would not be portable
to, e.g., terminal-interfacing systems.
Looking at what Gforth, SwiftForth, and VFX do on Linux, I find that
all three are terminal programs. You cannot EKEY Ctrl-C and Ctrl-Z
with any of them by default; you cannot EKEY Ctrl-S and Ctrl-Q in
Gforth and VFX by default; they serve their function of allowing
flow-control. You can EKEY Ctrl-S and Ctrl-Q in SwiftForth, but OTOH
there is no obvious way to perform flow control in SwiftForth (neither
the ScrollLock nor the Pause key have that effect).
- 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
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-03-12 04:20 +0000 |
| Message-ID | <xn0kndw231x9ddh004@nntp.aioe.org> |
| In reply to | #55054 |
lehs wrote: > There is an other problem with EKEY in GForth: > > 32-bit Windows makes no difference of e.g. 'right arrow' and 'ctrl > right arrow'. Bad, since 'ctrl right arrow' is used for 'next word'. Windows certainly does. I don't know if GForth does, though. -- Rudy Velthuis http://www.rvelthuis.de "There are worse things in life than death. Have you ever spent an evening with an insurance salesman?" -- Woody Allen
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-25 05:14 -0800 |
| Message-ID | <b7d59ac0-715d-47b4-a09f-f2135f6400f5@googlegroups.com> |
| In reply to | #55038 |
SP-Forth for Windows seems to manage the idea of ANS: 1020031 1 1030032 2 1040033 3 1100051 q 1110057 w 1120045 e 1130072 r 1140074 t 1150079 y My leftmost keys 101001B ESC 12900F5 § 10F0009 TAB 13A0000 CAPS LOCK 12A0000 SHIFT 11D0000 CTRL The rightmost SHIFT 1360000 SHIFT The arrows 14B0000 LEFT 1480000 UP 14D0000 RIGHT 1500000 DOWN
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-25 16:24 -0500 |
| Message-ID | <o8ssib$v71$1@dont-email.me> |
| In reply to | #55098 |
On 2/25/2017 8:14 AM, lehs wrote: > SP-Forth for Windows seems to manage the idea of ANS: > > 1020031 1 > 1030032 2 > 1040033 3 > > 1100051 q > 1110057 w > 1120045 e > 1130072 r > 1140074 t > 1150079 y > > My leftmost keys > 101001B ESC > 12900F5 § > 10F0009 TAB > 13A0000 CAPS LOCK > 12A0000 SHIFT > 11D0000 CTRL > > The rightmost SHIFT > 1360000 SHIFT > > The arrows > 14B0000 LEFT > 1480000 UP > 14D0000 RIGHT > 1500000 DOWN If your system reports things like the shift key being pressed, does it also report the shift key being released? Or does it report other keys differently when shift, cntl and alt are pressed in the eight combinations? What about device specific keys like the "Fn" key on my laptop? Or are you on a desktop? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-25 18:48 -0800 |
| Message-ID | <40a3d82e-956e-490a-bfdc-d7bb1443ea04@googlegroups.com> |
| In reply to | #55103 |
Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: > On 2/25/2017 8:14 AM, lehs wrote: > > SP-Forth for Windows seems to manage the idea of ANS: > > > > 1020031 1 > > 1030032 2 > > 1040033 3 > > > > 1100051 q > > 1110057 w > > 1120045 e > > 1130072 r > > 1140074 t > > 1150079 y > > > > My leftmost keys > > 101001B ESC > > 12900F5 § > > 10F0009 TAB > > 13A0000 CAPS LOCK > > 12A0000 SHIFT > > 11D0000 CTRL > > > > The rightmost SHIFT > > 1360000 SHIFT > > > > The arrows > > 14B0000 LEFT > > 1480000 UP > > 14D0000 RIGHT > > 1500000 DOWN > > If your system reports things like the shift key being pressed, does it > also report the shift key being released? Or does it report other keys > differently when shift, cntl and alt are pressed in the eight > combinations? What about device specific keys like the "Fn" key on my > laptop? Or are you on a desktop? > > -- > > Rick C It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). I use a HP laptop.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-25 23:41 -0500 |
| Message-ID | <o8tm6a$1pk$2@dont-email.me> |
| In reply to | #55104 |
On 2/25/2017 9:48 PM, lehs wrote: > Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: >> On 2/25/2017 8:14 AM, lehs wrote: >>> SP-Forth for Windows seems to manage the idea of ANS: >>> >>> 1020031 1 >>> 1030032 2 >>> 1040033 3 >>> >>> 1100051 q >>> 1110057 w >>> 1120045 e >>> 1130072 r >>> 1140074 t >>> 1150079 y >>> >>> My leftmost keys >>> 101001B ESC >>> 12900F5 § >>> 10F0009 TAB >>> 13A0000 CAPS LOCK >>> 12A0000 SHIFT >>> 11D0000 CTRL >>> >>> The rightmost SHIFT >>> 1360000 SHIFT >>> >>> The arrows >>> 14B0000 LEFT >>> 1480000 UP >>> 14D0000 RIGHT >>> 1500000 DOWN >> >> If your system reports things like the shift key being pressed, does it >> also report the shift key being released? Or does it report other keys >> differently when shift, cntl and alt are pressed in the eight >> combinations? What about device specific keys like the "Fn" key on my >> laptop? Or are you on a desktop? >> >> -- >> >> Rick C > > It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). > > I use a HP laptop. I'm not sure what you intend by "consequent". If the shift and control keys are to be used as modifier, it is required to know when they are pressed as well as when they are released unless the keyboard or other software is performing the modifications of the other keys for you. If you press and hold the shift key while typing "THIS IS ALL CAPS", some software somewhere has to know when the shift key was released. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-26 00:48 -0800 |
| Message-ID | <c733a3bf-7ba6-4636-a3d1-47464ffd842a@googlegroups.com> |
| In reply to | #55106 |
Den söndag 26 februari 2017 kl. 05:41:34 UTC+1 skrev rickman: > On 2/25/2017 9:48 PM, lehs wrote: > > Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: > >> On 2/25/2017 8:14 AM, lehs wrote: > >>> SP-Forth for Windows seems to manage the idea of ANS: > >>> > >>> 1020031 1 > >>> 1030032 2 > >>> 1040033 3 > >>> > >>> 1100051 q > >>> 1110057 w > >>> 1120045 e > >>> 1130072 r > >>> 1140074 t > >>> 1150079 y > >>> > >>> My leftmost keys > >>> 101001B ESC > >>> 12900F5 § > >>> 10F0009 TAB > >>> 13A0000 CAPS LOCK > >>> 12A0000 SHIFT > >>> 11D0000 CTRL > >>> > >>> The rightmost SHIFT > >>> 1360000 SHIFT > >>> > >>> The arrows > >>> 14B0000 LEFT > >>> 1480000 UP > >>> 14D0000 RIGHT > >>> 1500000 DOWN > >> > >> If your system reports things like the shift key being pressed, does it > >> also report the shift key being released? Or does it report other keys > >> differently when shift, cntl and alt are pressed in the eight > >> combinations? What about device specific keys like the "Fn" key on my > >> laptop? Or are you on a desktop? > >> > >> -- > >> > >> Rick C > > > > It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). > > > > I use a HP laptop. > > I'm not sure what you intend by "consequent". > > If the shift and control keys are to be used as modifier, it is required > to know when they are pressed as well as when they are released unless > the keyboard or other software is performing the modifications of the > other keys for you. If you press and hold the shift key while typing > "THIS IS ALL CAPS", some software somewhere has to know when the shift > key was released. > > -- > > Rick C I will use a combination of this EKEY and KEY that I think will work fine.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-26 03:13 -0800 |
| Message-ID | <4437aca3-dea6-48a9-a651-133c06f19ef3@googlegroups.com> |
| In reply to | #55109 |
Den söndag 26 februari 2017 kl. 09:48:26 UTC+1 skrev lehs: > Den söndag 26 februari 2017 kl. 05:41:34 UTC+1 skrev rickman: > > On 2/25/2017 9:48 PM, lehs wrote: > > > Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: > > >> On 2/25/2017 8:14 AM, lehs wrote: > > >>> SP-Forth for Windows seems to manage the idea of ANS: > > >>> > > >>> 1020031 1 > > >>> 1030032 2 > > >>> 1040033 3 > > >>> > > >>> 1100051 q > > >>> 1110057 w > > >>> 1120045 e > > >>> 1130072 r > > >>> 1140074 t > > >>> 1150079 y > > >>> > > >>> My leftmost keys > > >>> 101001B ESC > > >>> 12900F5 § > > >>> 10F0009 TAB > > >>> 13A0000 CAPS LOCK > > >>> 12A0000 SHIFT > > >>> 11D0000 CTRL > > >>> > > >>> The rightmost SHIFT > > >>> 1360000 SHIFT > > >>> > > >>> The arrows > > >>> 14B0000 LEFT > > >>> 1480000 UP > > >>> 14D0000 RIGHT > > >>> 1500000 DOWN > > >> > > >> If your system reports things like the shift key being pressed, does it > > >> also report the shift key being released? Or does it report other keys > > >> differently when shift, cntl and alt are pressed in the eight > > >> combinations? What about device specific keys like the "Fn" key on my > > >> laptop? Or are you on a desktop? > > >> > > >> -- > > >> > > >> Rick C > > > > > > It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). > > > > > > I use a HP laptop. > > > > I'm not sure what you intend by "consequent". > > > > If the shift and control keys are to be used as modifier, it is required > > to know when they are pressed as well as when they are released unless > > the keyboard or other software is performing the modifications of the > > other keys for you. If you press and hold the shift key while typing > > "THIS IS ALL CAPS", some software somewhere has to know when the shift > > key was released. > > > > -- > > > > Rick C > > I will use a combination of this EKEY and KEY that I think will work fine. This seems to work: 0x0140 CONSTANT FENCE \ lim between act keys and pre keys 0xFFFF CONSTANT MASK \ mask ascii from EKEY code : KEY* \ -- code EKEY DUP MASK AND \ ascii? IF MASK AND EXIT THEN \ ascii code 16 RSHIFT DUP FENCE > \ action key? IF EXIT \ action code THEN DROP KEY ; \ double keystroke Everything works except ^C in the new console in Windows 10, if inactivate the ctrl-shortcut keys.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-26 15:27 -0500 |
| Message-ID | <o8vdkd$d2n$1@dont-email.me> |
| In reply to | #55114 |
On 2/26/2017 6:13 AM, lehs wrote: > Den söndag 26 februari 2017 kl. 09:48:26 UTC+1 skrev lehs: >> Den söndag 26 februari 2017 kl. 05:41:34 UTC+1 skrev rickman: >>> On 2/25/2017 9:48 PM, lehs wrote: >>>> Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: >>>>> On 2/25/2017 8:14 AM, lehs wrote: >>>>>> SP-Forth for Windows seems to manage the idea of ANS: >>>>>> >>>>>> 1020031 1 >>>>>> 1030032 2 >>>>>> 1040033 3 >>>>>> >>>>>> 1100051 q >>>>>> 1110057 w >>>>>> 1120045 e >>>>>> 1130072 r >>>>>> 1140074 t >>>>>> 1150079 y >>>>>> >>>>>> My leftmost keys >>>>>> 101001B ESC >>>>>> 12900F5 § >>>>>> 10F0009 TAB >>>>>> 13A0000 CAPS LOCK >>>>>> 12A0000 SHIFT >>>>>> 11D0000 CTRL >>>>>> >>>>>> The rightmost SHIFT >>>>>> 1360000 SHIFT >>>>>> >>>>>> The arrows >>>>>> 14B0000 LEFT >>>>>> 1480000 UP >>>>>> 14D0000 RIGHT >>>>>> 1500000 DOWN >>>>> >>>>> If your system reports things like the shift key being pressed, does it >>>>> also report the shift key being released? Or does it report other keys >>>>> differently when shift, cntl and alt are pressed in the eight >>>>> combinations? What about device specific keys like the "Fn" key on my >>>>> laptop? Or are you on a desktop? >>>>> >>>>> -- >>>>> >>>>> Rick C >>>> >>>> It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). >>>> >>>> I use a HP laptop. >>> >>> I'm not sure what you intend by "consequent". >>> >>> If the shift and control keys are to be used as modifier, it is required >>> to know when they are pressed as well as when they are released unless >>> the keyboard or other software is performing the modifications of the >>> other keys for you. If you press and hold the shift key while typing >>> "THIS IS ALL CAPS", some software somewhere has to know when the shift >>> key was released. >>> >>> -- >>> >>> Rick C >> >> I will use a combination of this EKEY and KEY that I think will work fine. > This seems to work: > > 0x0140 CONSTANT FENCE \ lim between act keys and pre keys > 0xFFFF CONSTANT MASK \ mask ascii from EKEY code > > : KEY* \ -- code > EKEY DUP MASK AND \ ascii? > IF MASK AND EXIT THEN \ ascii code > 16 RSHIFT DUP FENCE > \ action key? > IF EXIT \ action code > THEN DROP KEY ; \ double keystroke > > Everything works except ^C in the new console in Windows 10, if inactivate the ctrl-shortcut keys. So standard ASCII keys set bits in the lower two bytes. I assume the use of the mask before exiting means upper bits could be set? Any idea why that is? "Action codes" means what exactly? Was the 140 fence determined empirically? What keys are between 140 and 127 (the top of the ASCII codes)? Finally why do codes below 140 imply double keystroke? Do you understand how EKEY and KEY interact? I don't follow why KEY is read under some conditions. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-26 23:39 -0800 |
| Message-ID | <b642fbf2-1017-4047-8cbb-4b7474f72746@googlegroups.com> |
| In reply to | #55126 |
Den söndag 26 februari 2017 kl. 21:27:46 UTC+1 skrev rickman: > On 2/26/2017 6:13 AM, lehs wrote: > > Den söndag 26 februari 2017 kl. 09:48:26 UTC+1 skrev lehs: > >> Den söndag 26 februari 2017 kl. 05:41:34 UTC+1 skrev rickman: > >>> On 2/25/2017 9:48 PM, lehs wrote: > >>>> Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: > >>>>> On 2/25/2017 8:14 AM, lehs wrote: > >>>>>> SP-Forth for Windows seems to manage the idea of ANS: > >>>>>> > >>>>>> 1020031 1 > >>>>>> 1030032 2 > >>>>>> 1040033 3 > >>>>>> > >>>>>> 1100051 q > >>>>>> 1110057 w > >>>>>> 1120045 e > >>>>>> 1130072 r > >>>>>> 1140074 t > >>>>>> 1150079 y > >>>>>> > >>>>>> My leftmost keys > >>>>>> 101001B ESC > >>>>>> 12900F5 § > >>>>>> 10F0009 TAB > >>>>>> 13A0000 CAPS LOCK > >>>>>> 12A0000 SHIFT > >>>>>> 11D0000 CTRL > >>>>>> > >>>>>> The rightmost SHIFT > >>>>>> 1360000 SHIFT > >>>>>> > >>>>>> The arrows > >>>>>> 14B0000 LEFT > >>>>>> 1480000 UP > >>>>>> 14D0000 RIGHT > >>>>>> 1500000 DOWN > >>>>> > >>>>> If your system reports things like the shift key being pressed, does it > >>>>> also report the shift key being released? Or does it report other keys > >>>>> differently when shift, cntl and alt are pressed in the eight > >>>>> combinations? What about device specific keys like the "Fn" key on my > >>>>> laptop? Or are you on a desktop? > >>>>> > >>>>> -- > >>>>> > >>>>> Rick C > >>>> > >>>> It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). > >>>> > >>>> I use a HP laptop. > >>> > >>> I'm not sure what you intend by "consequent". > >>> > >>> If the shift and control keys are to be used as modifier, it is required > >>> to know when they are pressed as well as when they are released unless > >>> the keyboard or other software is performing the modifications of the > >>> other keys for you. If you press and hold the shift key while typing > >>> "THIS IS ALL CAPS", some software somewhere has to know when the shift > >>> key was released. > >>> > >>> -- > >>> > >>> Rick C > >> > >> I will use a combination of this EKEY and KEY that I think will work fine. > > This seems to work: > > > > 0x0140 CONSTANT FENCE \ lim between act keys and pre keys > > 0xFFFF CONSTANT MASK \ mask ascii from EKEY code > > > > : KEY* \ -- code > > EKEY DUP MASK AND \ ascii? > > IF MASK AND EXIT THEN \ ascii code > > 16 RSHIFT DUP FENCE > \ action key? > > IF EXIT \ action code > > THEN DROP KEY ; \ double keystroke > > > > Everything works except ^C in the new console in Windows 10, if inactivate the ctrl-shortcut keys. > > So standard ASCII keys set bits in the lower two bytes. I assume the > use of the mask before exiting means upper bits could be set? Any idea > why that is? > > "Action codes" means what exactly? Was the 140 fence determined > empirically? What keys are between 140 and 127 (the top of the ASCII > codes)? Finally why do codes below 140 imply double keystroke? Do you > understand how EKEY and KEY interact? I don't follow why KEY is read > under some conditions. > > -- > > Rick C Of course FENCE is an empirical discovery. SP-Forth has compressed the result of EKEY into one single cell number, the upper two bytes for ascii keystrokes are not zero, but the lower two bytes for non ascii keystrokes are zero. If the result of EKEY is a single keystroke (ascii or arrow or something) the that result is returned (masked or shifted) else if ctrl or shift is pressed KEY will do the job. It works, as far as I have tested.
[toc] | [prev] | [next] | [standalone]
| From | peter.m.falth@gmail.com |
|---|---|
| Date | 2017-02-26 14:42 -0800 |
| Message-ID | <528ee52a-a43f-4a19-a0e6-c7c2c449f8b5@googlegroups.com> |
| In reply to | #55114 |
On Sunday, 26 February 2017 12:13:24 UTC+1, lehs wrote: > Den söndag 26 februari 2017 kl. 09:48:26 UTC+1 skrev lehs: > > Den söndag 26 februari 2017 kl. 05:41:34 UTC+1 skrev rickman: > > > On 2/25/2017 9:48 PM, lehs wrote: > > > > Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: > > > >> On 2/25/2017 8:14 AM, lehs wrote: > > > >>> SP-Forth for Windows seems to manage the idea of ANS: > > > >>> > > > >>> 1020031 1 > > > >>> 1030032 2 > > > >>> 1040033 3 > > > >>> > > > >>> 1100051 q > > > >>> 1110057 w > > > >>> 1120045 e > > > >>> 1130072 r > > > >>> 1140074 t > > > >>> 1150079 y > > > >>> > > > >>> My leftmost keys > > > >>> 101001B ESC > > > >>> 12900F5 § > > > >>> 10F0009 TAB > > > >>> 13A0000 CAPS LOCK > > > >>> 12A0000 SHIFT > > > >>> 11D0000 CTRL > > > >>> > > > >>> The rightmost SHIFT > > > >>> 1360000 SHIFT > > > >>> > > > >>> The arrows > > > >>> 14B0000 LEFT > > > >>> 1480000 UP > > > >>> 14D0000 RIGHT > > > >>> 1500000 DOWN > > > >> > > > >> If your system reports things like the shift key being pressed, does it > > > >> also report the shift key being released? Or does it report other keys > > > >> differently when shift, cntl and alt are pressed in the eight > > > >> combinations? What about device specific keys like the "Fn" key on my > > > >> laptop? Or are you on a desktop? > > > >> > > > >> -- > > > >> > > > >> Rick C > > > > > > > > It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). > > > > > > > > I use a HP laptop. > > > > > > I'm not sure what you intend by "consequent". > > > > > > If the shift and control keys are to be used as modifier, it is required > > > to know when they are pressed as well as when they are released unless > > > the keyboard or other software is performing the modifications of the > > > other keys for you. If you press and hold the shift key while typing > > > "THIS IS ALL CAPS", some software somewhere has to know when the shift > > > key was released. > > > > > > -- > > > > > > Rick C > > > > I will use a combination of this EKEY and KEY that I think will work fine. > This seems to work: > > 0x0140 CONSTANT FENCE \ lim between act keys and pre keys > 0xFFFF CONSTANT MASK \ mask ascii from EKEY code > > : KEY* \ -- code > EKEY DUP MASK AND \ ascii? > IF MASK AND EXIT THEN \ ascii code > 16 RSHIFT DUP FENCE > \ action key? > IF EXIT \ action code > THEN DROP KEY ; \ double keystroke > > Everything works except ^C in the new console in Windows 10, if inactivate the ctrl-shortcut keys. Why not use EKEY>CHAR that is in ANS? Then use EKEY>FKEY from forth2012 to get the function key 2012 also specifies names for the function keys. This would make your editor portable to other forths. If they do not support this words the porting effort is to define them BR Peter
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-26 18:20 -0500 |
| Message-ID | <o8vno6$iv6$1@dont-email.me> |
| In reply to | #55132 |
On 2/26/2017 5:42 PM, peter.m.falth@gmail.com wrote: > On Sunday, 26 February 2017 12:13:24 UTC+1, lehs wrote: >> Den söndag 26 februari 2017 kl. 09:48:26 UTC+1 skrev lehs: >>> Den söndag 26 februari 2017 kl. 05:41:34 UTC+1 skrev rickman: >>>> On 2/25/2017 9:48 PM, lehs wrote: >>>>> Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: >>>>>> On 2/25/2017 8:14 AM, lehs wrote: >>>>>>> SP-Forth for Windows seems to manage the idea of ANS: >>>>>>> >>>>>>> 1020031 1 >>>>>>> 1030032 2 >>>>>>> 1040033 3 >>>>>>> >>>>>>> 1100051 q >>>>>>> 1110057 w >>>>>>> 1120045 e >>>>>>> 1130072 r >>>>>>> 1140074 t >>>>>>> 1150079 y >>>>>>> >>>>>>> My leftmost keys >>>>>>> 101001B ESC >>>>>>> 12900F5 § >>>>>>> 10F0009 TAB >>>>>>> 13A0000 CAPS LOCK >>>>>>> 12A0000 SHIFT >>>>>>> 11D0000 CTRL >>>>>>> >>>>>>> The rightmost SHIFT >>>>>>> 1360000 SHIFT >>>>>>> >>>>>>> The arrows >>>>>>> 14B0000 LEFT >>>>>>> 1480000 UP >>>>>>> 14D0000 RIGHT >>>>>>> 1500000 DOWN >>>>>> >>>>>> If your system reports things like the shift key being pressed, does it >>>>>> also report the shift key being released? Or does it report other keys >>>>>> differently when shift, cntl and alt are pressed in the eight >>>>>> combinations? What about device specific keys like the "Fn" key on my >>>>>> laptop? Or are you on a desktop? >>>>>> >>>>>> -- >>>>>> >>>>>> Rick C >>>>> >>>>> It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). >>>>> >>>>> I use a HP laptop. >>>> >>>> I'm not sure what you intend by "consequent". >>>> >>>> If the shift and control keys are to be used as modifier, it is required >>>> to know when they are pressed as well as when they are released unless >>>> the keyboard or other software is performing the modifications of the >>>> other keys for you. If you press and hold the shift key while typing >>>> "THIS IS ALL CAPS", some software somewhere has to know when the shift >>>> key was released. >>>> >>>> -- >>>> >>>> Rick C >>> >>> I will use a combination of this EKEY and KEY that I think will work fine. >> This seems to work: >> >> 0x0140 CONSTANT FENCE \ lim between act keys and pre keys >> 0xFFFF CONSTANT MASK \ mask ascii from EKEY code >> >> : KEY* \ -- code >> EKEY DUP MASK AND \ ascii? >> IF MASK AND EXIT THEN \ ascii code >> 16 RSHIFT DUP FENCE > \ action key? >> IF EXIT \ action code >> THEN DROP KEY ; \ double keystroke >> >> Everything works except ^C in the new console in Windows 10, if inactivate the ctrl-shortcut keys. > > Why not use EKEY>CHAR that is in ANS? > > Then use EKEY>FKEY from forth2012 to get the function key > > 2012 also specifies names for the function keys. > > This would make your editor portable to other forths. > If they do not support this words the porting effort is to define them That seems to make it easy. A couple of IFs and Bob's your uncle! I noticed that section 10.6.2.1306.40 EKEY>FKEY has a typo in the stack comment. They don't show the two cases where the key was/was not a function key like they do for EKEY>CHAR 10.6.2.1306 EKEY>CHAR ( x -- x false | char true ) 10.6.2.1306.40 EKEY>FKEY ( x -- u flag ) I'm glad this topic was discussed here. This may be very useful someday. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-26 23:43 -0800 |
| Message-ID | <bd52d3e0-8d01-4243-aeea-d3df2f5d8d4c@googlegroups.com> |
| In reply to | #55132 |
Den söndag 26 februari 2017 kl. 23:42:21 UTC+1 skrev peter....@gmail.com: > On Sunday, 26 February 2017 12:13:24 UTC+1, lehs wrote: > > Den söndag 26 februari 2017 kl. 09:48:26 UTC+1 skrev lehs: > > > Den söndag 26 februari 2017 kl. 05:41:34 UTC+1 skrev rickman: > > > > On 2/25/2017 9:48 PM, lehs wrote: > > > > > Den lördag 25 februari 2017 kl. 22:24:15 UTC+1 skrev rickman: > > > > >> On 2/25/2017 8:14 AM, lehs wrote: > > > > >>> SP-Forth for Windows seems to manage the idea of ANS: > > > > >>> > > > > >>> 1020031 1 > > > > >>> 1030032 2 > > > > >>> 1040033 3 > > > > >>> > > > > >>> 1100051 q > > > > >>> 1110057 w > > > > >>> 1120045 e > > > > >>> 1130072 r > > > > >>> 1140074 t > > > > >>> 1150079 y > > > > >>> > > > > >>> My leftmost keys > > > > >>> 101001B ESC > > > > >>> 12900F5 § > > > > >>> 10F0009 TAB > > > > >>> 13A0000 CAPS LOCK > > > > >>> 12A0000 SHIFT > > > > >>> 11D0000 CTRL > > > > >>> > > > > >>> The rightmost SHIFT > > > > >>> 1360000 SHIFT > > > > >>> > > > > >>> The arrows > > > > >>> 14B0000 LEFT > > > > >>> 1480000 UP > > > > >>> 14D0000 RIGHT > > > > >>> 1500000 DOWN > > > > >> > > > > >> If your system reports things like the shift key being pressed, does it > > > > >> also report the shift key being released? Or does it report other keys > > > > >> differently when shift, cntl and alt are pressed in the eight > > > > >> combinations? What about device specific keys like the "Fn" key on my > > > > >> laptop? Or are you on a desktop? > > > > >> > > > > >> -- > > > > >> > > > > >> Rick C > > > > > > > > > > It works like KEY but with physical single keystrokes. It's not perfectly consequent, left shift differ from right shift but left ctrl equals to right ctrl and the fn key is ignored (as some other keys for volume etc). > > > > > > > > > > I use a HP laptop. > > > > > > > > I'm not sure what you intend by "consequent". > > > > > > > > If the shift and control keys are to be used as modifier, it is required > > > > to know when they are pressed as well as when they are released unless > > > > the keyboard or other software is performing the modifications of the > > > > other keys for you. If you press and hold the shift key while typing > > > > "THIS IS ALL CAPS", some software somewhere has to know when the shift > > > > key was released. > > > > > > > > -- > > > > > > > > Rick C > > > > > > I will use a combination of this EKEY and KEY that I think will work fine. > > This seems to work: > > > > 0x0140 CONSTANT FENCE \ lim between act keys and pre keys > > 0xFFFF CONSTANT MASK \ mask ascii from EKEY code > > > > : KEY* \ -- code > > EKEY DUP MASK AND \ ascii? > > IF MASK AND EXIT THEN \ ascii code > > 16 RSHIFT DUP FENCE > \ action key? > > IF EXIT \ action code > > THEN DROP KEY ; \ double keystroke > > > > Everything works except ^C in the new console in Windows 10, if inactivate the ctrl-shortcut keys. > > Why not use EKEY>CHAR that is in ANS? > > Then use EKEY>FKEY from forth2012 to get the function key > > 2012 also specifies names for the function keys. > > This would make your editor portable to other forths. > If they do not support this words the porting effort is to define them > > BR > Peter I haven't tried that. Thanks! I would really like to make an editor that works with all ANS Forth systems.
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | comp.lang.forth
csiph-web