hello

how could I trap ctrl+c key to call a word ?
just like

: test
\ some stuff
key
case
81 of dosomething endof
ctrlc of callaword endof
\etc...
;

without breaking forth interpretor execution but really using it as a key or input flow

currently whatever I tryied yet continues to use ctrl-c as BREAK signal...

In article <08895bfe-78fe-486c-83ef-9cce636a790fn@googlegroups.com>,
gobli...@gmail.com <goblinrieur@gmail.com> wrote:
>hello
>
>how could I trap ctrl+c key to call a word ?
>just like
>
>: test
>\ some stuff
>key
>case
>81 of dosomething endof
>ctrlc of callaword endof
>\etc...
>;
>
>without breaking forth interpretor execution but really using it as a
>key or input flow
>
>currently whatever I tryied yet continues to use ctrl-c as BREAK signal...
>
It is unbelievable that some one posts this kind of question without
mentioning the compiler or operating system.
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Wednesday, August 16, 2023 at 2:17:05 PM UTC-4, none albert wrote:

> It is unbelievable that some one posts this kind of question without
> mentioning the compiler or operating system.

I get the sense that younger people think of GForth like they think of GCC.
ie: GForth "is" Forth. What else would you use bro'? :-)

Le mercredi 16 août 2023 à 20:17:05 UTC+2, none albert a écrit :
> In article <08895bfe-78fe-486c...@googlegroups.com>,
> gobli...@gmail.com <gobli...@gmail.com> wrote:
> >hello
> >
> >how could I trap ctrl+c key to call a word ?
> >just like
> >
> >: test
> >\ some stuff
> >key
> >case
> >81 of dosomething endof
> >ctrlc of callaword endof
> >\etc...
> >;
> >
> >without breaking forth interpretor execution but really using it as a
> >key or input flow
> >
> >currently whatever I tryied yet continues to use ctrl-c as BREAK signal....
> >
> It is unbelievable that some one posts this kind of question without
> mentioning the compiler or operating system.
> --
> Don't praise the day before the evening. One swallow doesn't make spring.
> You must not say "hey" before you have crossed the bridge. Don't sell the
> hide of the bear until you shot it. Better one bird in the hand than ten in
> the air. First gain is a cat spinning. - the Wise from Antrim -

this was general purpose question, not specific to one or one other forth interpretor for any operating system ! so of course I could'nt mention a system in the question

On 17/08/2023 5:22 am, Brian Fox wrote:
> On Wednesday, August 16, 2023 at 2:17:05 PM UTC-4, none albert wrote:
>
>> It is unbelievable that some one posts this kind of question without
>> mentioning the compiler or operating system.
>
> I get the sense that younger people think of GForth like they think of GCC.
> ie: GForth "is" Forth. What else would you use bro'? :-)

"Computer says no"

Le mercredi 16 août 2023 à 21:22:13 UTC+2, Brian Fox a écrit :
> On Wednesday, August 16, 2023 at 2:17:05 PM UTC-4, none albert wrote:
>
> > It is unbelievable that some one posts this kind of question without
> > mentioning the compiler or operating system.
> I get the sense that younger people think of GForth like they think of GCC.
> ie: GForth "is" Forth. What else would you use bro'? :-)

Hello,

On other forum someone give a clue, specific to gforth but might be usable/adaptable to other forth interpretors.

Redefining the "key" word as :

-28 constant key-ctrl-c-ior \ trap control+c key code for the gforth interpretor
: key ( -- x ) \ redefine key to manage trap on CTRL+C
['] key catch dup key-ctrl-c-ior = if exit then throw
;

and this does the job.

Le jeudi 17 août 2023 à 06:30:01 UTC+2, gobli...@gmail.com a écrit :
> Le mercredi 16 août 2023 à 21:22:13 UTC+2, Brian Fox a écrit :
> > On Wednesday, August 16, 2023 at 2:17:05 PM UTC-4, none albert wrote:
> >
> > > It is unbelievable that some one posts this kind of question without
> > > mentioning the compiler or operating system.
> > I get the sense that younger people think of GForth like they think of GCC.
> > ie: GForth "is" Forth. What else would you use bro'? :-)
> Hello,
>
> On other forum someone give a clue, specific to gforth but might be usable/adaptable to other forth interpretors.
>
> Redefining the "key" word as :
>
> -28 constant key-ctrl-c-ior \ trap control+c key code for the gforth interpretor
> : key ( -- x ) \ redefine key to manage trap on CTRL+C
> ['] key catch dup key-ctrl-c-ior = if exit then throw
> ;
>
> and this does the job.

the same idea can be used to call a special action with
: main
['] main catch
case ( ior )
\ ....
key-ctrl-c-ior of dostuff 0 (bye) endof
\ ...
endcase
;

"gobli...@gmail.com" <goblinrieur@gmail.com> writes:
>this was general purpose question, not specific to one or one other forth i=
>nterpretor for any operating system ! so of course I could'nt mention a sy=
>stem in the question

But it depends on the operating system.

In particular, I can tell you how to do it on Unix. On Unix, the
terminal handler by default catches the Ctrl-C coming from the
terminal and does not pass it as a key press to the application (e.g.,
a Forth system), but instead sends a SIGINT signal. So the way to do
what you want is to change this behaviour of the terminal handler.
E.g., you can change the terminal handler to use Ctrl-_ instead of
Ctrl-C for sending SIGINT with

stty intr '^_'

before starting the Forth system. I have done this and then tried

key .

in a number of Forth systems (Gforth, sf64, vfx64, iforth, lxf), and
pressed Ctrl-C when key waited for input. All these systems then
printed "3".

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <f72d3dbe-8e0a-441f-a424-1449865e968dn@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>On Wednesday, August 16, 2023 at 2:17:05 PM UTC-4, none albert wrote:
>
>> It is unbelievable that some one posts this kind of question without
>> mentioning the compiler or operating system.
>
>I get the sense that younger people think of GForth like they think of GCC.
>ie: GForth "is" Forth. What else would you use bro'? :-)

Even if we assume that GForth is so universal,
that doesn't cut it.
The answer is dependant on Gforth under MS-windows,
probably on versions, 0.7.3 and the latest, gforth fast etc.

Only if the team spent considerable effort to make this portable,
is there an answer.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

none albert schrieb am Donnerstag, 17. August 2023 um 12:08:08 UTC+2:
> In article <f72d3dbe-8e0a-441f...@googlegroups.com>,
> Brian Fox <bria...@brianfox.ca> wrote:
> >On Wednesday, August 16, 2023 at 2:17:05 PM UTC-4, none albert wrote:
> >
> >> It is unbelievable that some one posts this kind of question without
> >> mentioning the compiler or operating system.
> >
> >I get the sense that younger people think of GForth like they think of GCC.
> >ie: GForth "is" Forth. What else would you use bro'? :-)
> Even if we assume that GForth is so universal,
> that doesn't cut it.
> The answer is dependant on Gforth under MS-windows,
> probably on versions, 0.7.3 and the latest, gforth fast etc.

Even on Windoze you can use different terminals instead of the default
console. In addition Windows consoles have changed in the past
between different OS generations eg regarding ANSI VT support.

So there is no universal answer to the original question.

On Thursday, August 17, 2023 at 12:30:01 AM UTC-4, gobli...@gmail.com wrote:
> Le mercredi 16 août 2023 à 21:22:13 UTC+2, Brian Fox a écrit :
> > On Wednesday, August 16, 2023 at 2:17:05 PM UTC-4, none albert wrote:
> >
> > > It is unbelievable that some one posts this kind of question without
> > > mentioning the compiler or operating system.
> > I get the sense that younger people think of GForth like they think of GCC.
> > ie: GForth "is" Forth. What else would you use bro'? :-)
> Hello,
>
> On other forum someone give a clue, specific to gforth but might be usable/adaptable to other forth interpretors.
>
> Redefining the "key" word as :
>
> -28 constant key-ctrl-c-ior \ trap control+c key code for the gforth interpretor
> : key ( -- x ) \ redefine key to manage trap on CTRL+C
> ['] key catch dup key-ctrl-c-ior = if exit then throw
> ;
>
> and this does the job.

Since you seem to be trying to learn more about Forth I will say
congratulations on making the leap into something that might
challenge what you think you know about computers.

As you may have read here in the other posts, for better or worse, your
code will work on GForth and only on GForth.
Something similar may exist in another Forth for the same hardware but
it might use a different name for "key-ctrl-c-ior". Or it may not have that
feature at all and you would expected to write it yourself.

It's hard for programmers who work on a desktop with an operating system
and big languages to GROK that Forth can also run on and a tiny system
with 8Kbytes of memory.
But of course such a system has made compromises to only include what is
really needed and will bear very little resemblance to a desktop Forth.

The saying by the late Neil Baud is:
"If you have seen one Forth, you have seen ONE Forth."

Enjoy your journey.

On 17/08/2023 10:04 pm, minforth wrote:
> none albert schrieb am Donnerstag, 17. August 2023 um 12:08:08 UTC+2:
>> In article <f72d3dbe-8e0a-441f...@googlegroups.com>,
>> Brian Fox <bria...@brianfox.ca> wrote:
>>> On Wednesday, August 16, 2023 at 2:17:05 PM UTC-4, none albert wrote:
>>>
>>>> It is unbelievable that some one posts this kind of question without
>>>> mentioning the compiler or operating system.
>>>
>>> I get the sense that younger people think of GForth like they think of GCC.
>>> ie: GForth "is" Forth. What else would you use bro'? :-)
>> Even if we assume that GForth is so universal,
>> that doesn't cut it.
>> The answer is dependant on Gforth under MS-windows,
>> probably on versions, 0.7.3 and the latest, gforth fast etc.
>
> Even on Windoze you can use different terminals instead of the default
> console. In addition Windows consoles have changed in the past
> between different OS generations eg regarding ANSI VT support.
>
> So there is no universal answer to the original question.

What he said. It's the implementer's job to sort this stuff out assuming
support for the platform. In addition to the ctrl-c issue, Gforth Win
doesn't respond to crtl-s, ctrl-q, ctrl-z. The last Win release was three
years ago. This tells me it's either low priority or no longer supported.
That's fine. It's in the conditions of use - no warranty.

"gobli...@gmail.com" <goblinrieur@gmail.com> writes:
> -28 constant key-ctrl-c-ior \ trap control+c key code for the gforth interpretor
>: key ( -- x ) \ redefine key to manage trap on CTRL+C
> ['] key catch dup key-ctrl-c-ior = if exit then throw
>;

This produces -28 as result of KEY in case of a Ctrl-C. The value 3
(what you get if Ctrl-C is not converted into a signal) would be more
appropriate. I.e.:

-28 constant key-ctrl-c-ior \ trap control+c key code for the gforth interpretor
: key ( -- x ) \ redefine key to manage trap on CTRL+C
['] key catch dup key-ctrl-c-ior = if drop 3 exit then throw ;

This works on Gforth without having to reconfigure the environment to
actually pass through the Ctrl-C as key, but testing it on sd64,
vfx64, iforth, lxf, it does not work on any other system (only iforth
converts the signal into a Forth exception, but it does not throw
-28).

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

Brian Fox <brian.fox@brianfox.ca> writes:
>On Thursday, August 17, 2023 at 12:30:01=E2=80=AFAM UTC-4, gobli...@gmail.c=
>om wrote:
>> -28 constant key-ctrl-c-ior \ trap control+c key code for the gforth inte=
>rpretor=20
>> : key ( -- x ) \ redefine key to manage trap on CTRL+C=20
>> ['] key catch dup key-ctrl-c-ior =3D if exit then throw=20
>> ;=20
....
>As you may have read here in the other posts, for better or worse, your
>code will work on GForth and only on GForth.=20
>Something similar may exist in another Forth for the same hardware but
>it might use a different name for "key-ctrl-c-ior".

The name does not come from Gforth, but the OP introduced it. The
exception number -28 comes from the standard ("User Interrupt"), and
all the words used above are standard words, but you are still right,
among the five systems I tested, this works only in Gforth.

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <2023Aug18.112528@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"gobli...@gmail.com" <goblinrieur@gmail.com> writes:
>> -28 constant key-ctrl-c-ior \ trap control+c key code for the gforth
>interpretor
>>: key ( -- x ) \ redefine key to manage trap on CTRL+C
>> ['] key catch dup key-ctrl-c-ior = if exit then throw
>>;
>
>This produces -28 as result of KEY in case of a Ctrl-C. The value 3
>(what you get if Ctrl-C is not converted into a signal) would be more
>appropriate. I.e.:
>
>-28 constant key-ctrl-c-ior \ trap control+c key code for the gforth interpretor
>: key ( -- x ) \ redefine key to manage trap on CTRL+C
> ['] key catch dup key-ctrl-c-ior = if drop 3 exit then throw ;
>
>This works on Gforth without having to reconfigure the environment to
>actually pass through the Ctrl-C as key, but testing it on sd64,
>vfx64, iforth, lxf, it does not work on any other system (only iforth
>converts the signal into a Forth exception, but it does not throw
>-28).

As much as Gforth tries to shield user from unexpected things,
one must pay great attention to all control and interrupt keys.
They are named control for a reason.
For example you can trap keys that are intended to be interrupting.
But consider this case [ ubuntu/gnome/gforth 0.7.3 ]

~/PROJECT/ciforths/ciforth/LISPAOL/mal-forth/tests: gforth
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
KEY

[ ^S / ^Q holds output temporarily on a scrolling terminal ]

Now type in ^S. KEY has received 13 allright, but nothing seems
to be happening. It becomes apparent if you type ^Q. All the
stuff you have typed shows on the screen.
If you type only ^Q you can see the 13.
If type `` .S '' 13 has disappeared. And the code for ^Q (17)
nowhere to be seen.

Even weirder is if you type in ^Q and then return.
Now you expect 17, but it is actually ... 13.

So hold on to what the standard permits, and if you must use it
be aware under what circumstances it works.

You can hang a VT100 terminal (or an emulator) off a Linux system.
You can run an editor like vim allright (if you tell him to use
VT100 for the terminal capacity database.)
But the behaviour of ^S/^Q is confined to the terminal and Linux
can not know what happened.
>
>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

dxforth <dxforth@gmail.com> writes:
>In addition to the ctrl-c issue, Gforth Win
>doesn't respond to crtl-s, ctrl-q, ctrl-z.

In the following session on Unix, in the "key ." lines I pressed
Ctrl-C, Ctrl-S, CTRL-Q, and Ctrl-Z, in this order:

[~:142535] stty -a
speed 38400 baud; rows 50; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc
[~:142538] stty intr '' start '' stop '' susp ''
[~:142539] stty -a
speed 38400 baud; rows 50; columns 80; line = 0;
intr = <undef>; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>; susp = <undef>;
rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc
[~:142540] gforth
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
key . 3 ok
key . 19 ok
key . 17 ok
key . 26 ok

If Gforth does not respond to you pressing these keys, it's because
the environment does not pass them to Gforth.

As for "Gforth Win", using Gforth is certainly a win; or did you mean
something else?

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On Thursday, August 17, 2023 at 7:04:16 AM UTC-5, minforth wrote:
>
> So there is no universal answer to the original question.
I had good things to say about the ATARI 800 when I
found that useful system calls were exposed as
software pointer. Replaced their pointer to their
ctl-c handler to point to ValForth warm start and
all was good.
--
me

On 19/08/2023 1:19 am, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> In addition to the ctrl-c issue, Gforth Win
>> doesn't respond to crtl-s, ctrl-q, ctrl-z.
>
> key . 3 ok
> key . 19 ok
> key . 17 ok
> key . 26 ok
>
> If Gforth does not respond to you pressing these keys, it's because
> the environment does not pass them to Gforth.
>
> As for "Gforth Win", using Gforth is certainly a win; or did you mean
> something else?

Clearly it's a loss for Gforth application writers. If DOSBOX can
extract keystrokes from the Windows environment, so can others.

In article <ubpbgq$jjn1$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>On 19/08/2023 1:19 am, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>> In addition to the ctrl-c issue, Gforth Win
>>> doesn't respond to crtl-s, ctrl-q, ctrl-z.
>>
>> key . 3 ok
>> key . 19 ok
>> key . 17 ok
>> key . 26 ok
>>
>> If Gforth does not respond to you pressing these keys, it's because
>> the environment does not pass them to Gforth.
>>
>> As for "Gforth Win", using Gforth is certainly a win; or did you mean
>> something else?
>
>Clearly it's a loss for Gforth application writers. If DOSBOX can
>extract keystrokes from the Windows environment, so can others.
>

I don't think so. DOSBOX is a fairly primitive emulator, for a
fairly primitive system. But it is an *emulator* of an *environment*.
I was impressed that a Forth editor that writes directly in the
screen memory $B000 works in DOSBOX.

gforth and lina live in a rich environent of a gui etc.
They try to play nice with the environment and that greatly enhance
the usability of the compilers. For example both compilers can be
used as filters and scripts.
I can not give expert analysis of gforth but I can give an example
for lina.
lina doesn't have a command repeater (with cursor up) and have
limited line editing (only backspace).
But if you wish you can start lina as follows:
rlwrap lina
then rlwrap adds these facilities.

You can catch traps in the 32 bit version of lina, not so in the
64 bit version, and not so in the MS-Windows version.
Each require a separate effort and until such time they are not present.
The situation may be better in gforth because they can lean on
c-libraries. The burden of portability is merely shifted. The
c-libraries use different system calls to catch traps in 32 and 64 bit
system.

As Anton Ertl has pointed out the manipulations going on before
keys arriving into Forth are extensive. Always realize that
that requires adaptation to programs.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On 19/08/2023 6:40 pm, albert wrote:
> In article <ubpbgq$jjn1$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>> On 19/08/2023 1:19 am, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>> In addition to the ctrl-c issue, Gforth Win
>>>> doesn't respond to crtl-s, ctrl-q, ctrl-z.
>>>
>>> key . 3 ok
>>> key . 19 ok
>>> key . 17 ok
>>> key . 26 ok
>>>
>>> If Gforth does not respond to you pressing these keys, it's because
>>> the environment does not pass them to Gforth.
>>>
>>> As for "Gforth Win", using Gforth is certainly a win; or did you mean
>>> something else?
>>
>> Clearly it's a loss for Gforth application writers. If DOSBOX can
>> extract keystrokes from the Windows environment, so can others.
>>
>
> I don't think so. DOSBOX is a fairly primitive emulator, for a
> fairly primitive system. But it is an *emulator* of an *environment*.
> I was impressed that a Forth editor that writes directly in the
> screen memory $B000 works in DOSBOX.
> ...
> As Anton Ertl has pointed out the manipulations going on before
> keys arriving into Forth are extensive. Always realize that
> that requires adaptation to programs.

Win32Forth, SwiftForth, NT/Forth all work with the aforementioned keys
without issue. Quality of implementation? VFX handles them with the
exception of crtl-c.

In article <ubqchf$ptjj$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>On 19/08/2023 6:40 pm, albert wrote:
>> In article <ubpbgq$jjn1$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>>> On 19/08/2023 1:19 am, Anton Ertl wrote:
>>>> dxforth <dxforth@gmail.com> writes:
>>>>> In addition to the ctrl-c issue, Gforth Win
>>>>> doesn't respond to crtl-s, ctrl-q, ctrl-z.
>>>>
>>>> key . 3 ok
>>>> key . 19 ok
>>>> key . 17 ok
>>>> key . 26 ok
>>>>
>>>> If Gforth does not respond to you pressing these keys, it's because
>>>> the environment does not pass them to Gforth.
>>>>
>>>> As for "Gforth Win", using Gforth is certainly a win; or did you mean
>>>> something else?
>>>
>>> Clearly it's a loss for Gforth application writers. If DOSBOX can
>>> extract keystrokes from the Windows environment, so can others.
>>>
>>
>> I don't think so. DOSBOX is a fairly primitive emulator, for a
>> fairly primitive system. But it is an *emulator* of an *environment*.
>> I was impressed that a Forth editor that writes directly in the
>> screen memory $B000 works in DOSBOX.
>> ...
>> As Anton Ertl has pointed out the manipulations going on before
>> keys arriving into Forth are extensive. Always realize that
>> that requires adaptation to programs.
>
>Win32Forth, SwiftForth, NT/Forth all work with the aforementioned keys
>without issue. Quality of implementation? VFX handles them with the
>exception of crtl-c.
>

What do you mean? The function of ^C is to break off the program.
The function of ^\ is to break off the program with prejudice.
The function of ^S is to hold the program's output.
The function of ^Z is to put the program in the background (in linux).

Only in the context of single key presses can you say that they work
without issue, that is it returns the number that *you* expect.
The standard recognize printable character in the range {20..7E}.
A command line ends when an "implementation-defined line terminator is
received.".
Everything outside of this range is not portable, or implementation
defined.

In wina (running under wine) the line terminator is <return> ^J and ^M.
They map onto ^M (0x13) as far as KEY is concerned.
In lina (running under linux) the line terminator is <return> ^J and ^M.
They map onto ^J (0x10) as far as KEY is concerned.

Remember wordperfect? You could type 8bit characters with a alt
<number> . Why do you expand your expectations to the ALT key?

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On 20/08/2023 12:06 am, albert wrote:
> In article <ubqchf$ptjj$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>> On 19/08/2023 6:40 pm, albert wrote:
>>> In article <ubpbgq$jjn1$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>>>> On 19/08/2023 1:19 am, Anton Ertl wrote:
>>>>> dxforth <dxforth@gmail.com> writes:
>>>>>> In addition to the ctrl-c issue, Gforth Win
>>>>>> doesn't respond to crtl-s, ctrl-q, ctrl-z.
>>>>>
>>>>> key . 3 ok
>>>>> key . 19 ok
>>>>> key . 17 ok
>>>>> key . 26 ok
>>>>>
>>>>> If Gforth does not respond to you pressing these keys, it's because
>>>>> the environment does not pass them to Gforth.
>>>>>
>>>>> As for "Gforth Win", using Gforth is certainly a win; or did you mean
>>>>> something else?
>>>>
>>>> Clearly it's a loss for Gforth application writers. If DOSBOX can
>>>> extract keystrokes from the Windows environment, so can others.
>>>>
>>>
>>> I don't think so. DOSBOX is a fairly primitive emulator, for a
>>> fairly primitive system. But it is an *emulator* of an *environment*.
>>> I was impressed that a Forth editor that writes directly in the
>>> screen memory $B000 works in DOSBOX.
>>> ...
>>> As Anton Ertl has pointed out the manipulations going on before
>>> keys arriving into Forth are extensive. Always realize that
>>> that requires adaptation to programs.
>>
>> Win32Forth, SwiftForth, NT/Forth all work with the aforementioned keys
>> without issue. Quality of implementation? VFX handles them with the
>> exception of crtl-c.
>>
>
> What do you mean? The function of ^C is to break off the program.

The function of ^C is whatever the application determines it to be.
It would be a poor outcome if a WordStar user pressed ^C and the
program aborted.

On 8/19/23 9:59 AM, dxforth wrote:
>> What do you mean? The function of ^C is to break off the program.
>
> The function of ^C is whatever the application determines it to be.
> It would be a poor outcome if a WordStar user pressed ^C and the
> program aborted.
>
Only sort of true.

Going back to CP/M days, there were two type of console I/O available.

The usual route was to use a BDOS call and in this case the I/O was
"cooked" in that various things like ^C were handled. With no
interaction with the application.

You could bypass the things that the BDOS did to the console I/O and use
a direct BIOS call. This prevented the BDOS from ever seeing the
characters. Mostly.

As I found when using CP/M-68K which is variant of CP/M-2.2, calling the
BDOS console output function will result in the BDOS checking for an
input character. Just in case the user typed XOFF. So if you want to use
a BIOS call for input to avoid BDOS processing, you also have to use the
BIOS output call.

--
http://davesrocketworks.com
David Schultz

On 20/08/2023 5:55 am, David Schultz wrote:
> On 8/19/23 9:59 AM, dxforth wrote:
>>> What do you mean? The function of ^C is to break off the program.
>>
>> The function of ^C is whatever the application determines it to be.
>> It would be a poor outcome if a WordStar user pressed ^C and the
>> program aborted.
>>
> Only sort of true.
>
> Going back to CP/M days, there were two type of console I/O available.
>
> The usual route was to use a BDOS call and in this case the I/O was "cooked" in that various things like ^C were handled. With no interaction with the application.
>
> You could bypass the things that the BDOS did to the console I/O and use a direct BIOS call. This prevented the BDOS from ever seeing the characters. Mostly.
>

Same carried through to MS-DOS. Programmer had the choice of using cooked
I/O through INT21 or directly through INT16. In DX-Forth this is provided
through via functions DOS-IO and BIOS-IO.

> As I found when using CP/M-68K which is variant of CP/M-2.2, calling the BDOS console output function will result in the BDOS checking for an input character. Just in case the user typed XOFF. So if you want to use a BIOS call for input to avoid BDOS processing, you also have to use the BIOS output call.
>

For reasons I no longer recall DOS-IO under CP/M only redirects console output.
Input is still via BIOS. This meant intercepting ^C to exit the app.
XON XOFF presume the display is slow enough for a user to react - making them
useless on today's machines. Controlling a console listing is now left to the app.

On 8/16/23 10:29, gobli...@gmail.com wrote:
> hello
>
> how could I trap ctrl+c key to call a word ?
> just like
>
> : test
> \ some stuff
> key
> case
> 81 of dosomething endof
> ctrlc of callaword endof
> \etc...
> ;
>
....
In kForth (32 or 64-bit versions) running under Linux, a Forth handler
to respond to the SIGINT signal, generated when Ctrl-C is pressed, may
be installed as follows

include signal.4th

\ Define a handler for SIGINT

: ctrl-c-handler ( n -- ) drop cr ." Ctrl-C pressed." cr ;

\ Install handler using non-standard, kForth word FORTH-SIGNAL

' ctrl-c-handler SIGINT forth-signal drop

\ Now, press CTRL-c to test
^C
Ctrl-C pressed.

CATCH and THROW are not used for signal handling in kForth, so Anton's
example in redefining KEY would not work for returning a key code in
kForth, but KEY could be redefined to check a flag set by the handler,
and return a key code.

--
Krishna Myneni