Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #55164 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2017-02-27 01:51 -0800 |
| Last post | 2017-02-27 21:24 +0100 |
| Articles | 20 on this page of 121 — 16 participants |
Back to article view | Back to comp.lang.forth
Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 01:51 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 02:35 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 02:46 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-27 17:38 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 14:12 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 04:42 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 08:58 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 14:15 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 11:51 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 15:17 -0500
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 09:02 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 19:15 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-01 02:23 +0100
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 20:57 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-01 13:24 +0100
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:23 -0500
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-01 08:50 +0000
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 10:04 -0600
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:51 -0500
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-01 13:00 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-02 15:34 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-01 18:09 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:55 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-01 21:28 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-01 22:23 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-02 00:21 -0800
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-02 01:01 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-02 01:30 -0800
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-02 01:46 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-02 02:41 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-02 11:01 +0000
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-01 13:48 -0800
Re: Is GForth KEY really ANS Forth standard? antispam@math.uni.wroc.pl - 2017-03-04 04:02 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-04 12:29 +0000
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-02-28 03:24 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 04:14 -0800
Re: Is GForth KEY really ANS Forth standard? Coos Haak <htrofhc@gmail.com> - 2017-02-27 21:50 +0100
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 13:48 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 17:41 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 15:07 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 19:03 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 23:10 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 03:29 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 01:28 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 09:58 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 02:37 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 12:46 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 05:01 -0800
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-28 12:46 +0100
Re: Is GForth KEY really ANS Forth standard? Mikael Nordman <oh2aun@gmail.com> - 2017-02-28 03:52 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 04:10 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 05:48 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 10:07 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 02:42 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-02-28 02:44 -0800
Re: Is GForth KEY really ANS Forth standard? Coos Haak <htrofhc@gmail.com> - 2017-02-28 12:13 +0100
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-02-28 05:10 -0800
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-02-28 12:12 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 13:51 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-27 15:38 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 10:13 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-02-27 11:15 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-03 12:04 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-03 17:30 -0500
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-03 23:13 +0000
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-03 18:02 -0600
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-04 01:12 +0000
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-03 19:12 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-03 19:23 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:45 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:54 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-05 20:47 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 09:20 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 05:04 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 14:07 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 06:36 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 15:04 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:38 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:56 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-07 08:07 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-07 08:37 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:41 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 01:13 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 13:03 +0000
Re: Is GForth KEY really ANS Forth standard? julian.fondren@endurance.com - 2017-03-07 08:36 -0800
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-07 19:02 +0100
Re: Is GForth KEY really ANS Forth standard? alex@rivadpm.com - 2017-03-08 06:08 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 00:46 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 12:39 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 12:42 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 23:13 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 14:34 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:33 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:45 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-08 22:48 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 09:28 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 05:22 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 14:25 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 06:46 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 15:43 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-06 09:55 -0800
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-06 11:04 -0600
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:44 -0800
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-07 10:50 -0600
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 11:30 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 13:37 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 14:14 +0000
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-08 15:16 +0100
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 16:14 +0000
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 14:49 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-09 10:57 -0500
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:22 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-04 10:48 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-04 21:00 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-05 02:24 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-05 16:44 -0500
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-04 20:02 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-04 23:34 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-05 02:38 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-05 16:55 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-27 21:24 +0100
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-27 19:03 -0500 |
| Message-ID | <o92ekj$70q$1@dont-email.me> |
| In reply to | #55218 |
On 2/27/2017 6:07 PM, lehs wrote: > Den måndag 27 februari 2017 kl. 23:41:16 UTC+1 skrev rickman: >> On 2/27/2017 4:48 PM, lehs wrote: >>> Obiously something is very wrong. Why should KEY and EKEY in Forth systems running under Windows be distorted by some peculiarities from an other operating system, unix, with roots backs to the 60ties when people used terminals instead of laptops and mobiles? >>> >>> And obviously it is possible to do KEY and EKEY du9e to the ANS standard under Windows since Rufig actually did that. >>> >>> What's wrong with you guys? >> >> What is wrong with YOU? The issue has been explained clearly to you. >> If you don't like it why not *FIX YOUR SYSTEM* to not change the >> characters assigned to keys? >> >> For the last time, this is *NOT* a Forth problem. It is a Unix problem. >> That and a short between the headphones. >> >> -- >> >> Rick C > It's very easy to solve the problem by using SP-Forth. The issue was: KEY in GForth isn't ANS standard. You are saying that SP-Forth returns a cntl-H character when backspace is pressed but gForth returns a Del character? Even so, it has to do with the way the process is being handled by Unix. You need to fix the problem in Unix and all will be well. Do you know much about Unix? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-27 23:10 -0800 |
| Message-ID | <bf43a3a9-cb2d-4d3e-abdb-a5d60d0d1de4@googlegroups.com> |
| In reply to | #55220 |
Den tisdag 28 februari 2017 kl. 01:03:20 UTC+1 skrev rickman: > On 2/27/2017 6:07 PM, lehs wrote: > > Den måndag 27 februari 2017 kl. 23:41:16 UTC+1 skrev rickman: > >> On 2/27/2017 4:48 PM, lehs wrote: > >>> Obiously something is very wrong. Why should KEY and EKEY in Forth systems running under Windows be distorted by some peculiarities from an other operating system, unix, with roots backs to the 60ties when people used terminals instead of laptops and mobiles? > >>> > >>> And obviously it is possible to do KEY and EKEY du9e to the ANS standard under Windows since Rufig actually did that. > >>> > >>> What's wrong with you guys? > >> > >> What is wrong with YOU? The issue has been explained clearly to you. > >> If you don't like it why not *FIX YOUR SYSTEM* to not change the > >> characters assigned to keys? > >> > >> For the last time, this is *NOT* a Forth problem. It is a Unix problem. > >> That and a short between the headphones. > >> > >> -- > >> > >> Rick C > > It's very easy to solve the problem by using SP-Forth. The issue was: KEY in GForth isn't ANS standard. > > You are saying that SP-Forth returns a cntl-H character when backspace > is pressed but gForth returns a Del character? Even so, it has to do > with the way the process is being handled by Unix. You need to fix the > problem in Unix and all will be well. Do you know much about Unix? > > -- > > Rick C I know absolutely nothing about Unix except the confusion with backspace and delete, which is a minor problem. The problem with GForth is that KEY doesn't work due to Forth but due to Unix terminals. Since I'm testing to do a pure ANS Forth editor it wont work properly on GForth and perhaps not on Unix at all. I didn't know that GForth was so "infected" of Unix. I have ubuntu on a stick and I have tested it, but I'm glad I haven't installed it definitely since Unix seems to be such a meddlesome OS.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-28 03:29 -0500 |
| Message-ID | <o93c91$8kk$1@dont-email.me> |
| In reply to | #55232 |
On 2/28/2017 2:10 AM, lehs wrote: > Den tisdag 28 februari 2017 kl. 01:03:20 UTC+1 skrev rickman: >> On 2/27/2017 6:07 PM, lehs wrote: >>> Den måndag 27 februari 2017 kl. 23:41:16 UTC+1 skrev rickman: >>>> On 2/27/2017 4:48 PM, lehs wrote: >>>>> Obiously something is very wrong. Why should KEY and EKEY in >>>>> Forth systems running under Windows be distorted by some >>>>> peculiarities from an other operating system, unix, with >>>>> roots backs to the 60ties when people used terminals instead >>>>> of laptops and mobiles? >>>>> >>>>> And obviously it is possible to do KEY and EKEY du9e to the >>>>> ANS standard under Windows since Rufig actually did that. >>>>> >>>>> What's wrong with you guys? >>>> >>>> What is wrong with YOU? The issue has been explained clearly >>>> to you. If you don't like it why not *FIX YOUR SYSTEM* to not >>>> change the characters assigned to keys? >>>> >>>> For the last time, this is *NOT* a Forth problem. It is a Unix >>>> problem. That and a short between the headphones. >>>> >>>> -- >>>> >>>> Rick C >>> It's very easy to solve the problem by using SP-Forth. The issue >>> was: KEY in GForth isn't ANS standard. >> >> You are saying that SP-Forth returns a cntl-H character when >> backspace is pressed but gForth returns a Del character? Even so, >> it has to do with the way the process is being handled by Unix. >> You need to fix the problem in Unix and all will be well. Do you >> know much about Unix? >> >> -- >> >> Rick C > > I know absolutely nothing about Unix except the confusion with > backspace and delete, which is a minor problem. So far that is the only problem you have made clear. If you don't tell us what is happening we have no idea how to help you. If it is a "minor" problem, why are you complaining about it? I get that you know nothing of Unix. If you want to learn you can fix this. > The problem with GForth is that KEY doesn't work due to Forth but due > to Unix terminals. Since I'm testing to do a pure ANS Forth editor it > wont work properly on GForth and perhaps not on Unix at all. I didn't > know that GForth was so "infected" of Unix. Are you going to explain to us in what way KEY doesn't work other than the BS/delete problem? > I have ubuntu on a stick and I have tested it, but I'm glad I haven't > installed it definitely since Unix seems to be such a meddlesome OS. Your language is very inflammatory. If you want to support multiple OS then maybe you should learn something about them??? You are coming across like a child throwing a tantrum. Why not discuss the issues with us and maybe there will be a simple way to deal with this just as others were able to show you how to use EKEY properly. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-28 01:28 -0800 |
| Message-ID | <1625fce4-5a8f-43a1-a249-1dedcef01703@googlegroups.com> |
| In reply to | #55242 |
Den tisdag 28 februari 2017 kl. 09:29:10 UTC+1 skrev rickman: > On 2/28/2017 2:10 AM, lehs wrote: > > Den tisdag 28 februari 2017 kl. 01:03:20 UTC+1 skrev rickman: > >> On 2/27/2017 6:07 PM, lehs wrote: > >>> Den måndag 27 februari 2017 kl. 23:41:16 UTC+1 skrev rickman: > >>>> On 2/27/2017 4:48 PM, lehs wrote: > >>>>> Obiously something is very wrong. Why should KEY and EKEY in > >>>>> Forth systems running under Windows be distorted by some > >>>>> peculiarities from an other operating system, unix, with > >>>>> roots backs to the 60ties when people used terminals instead > >>>>> of laptops and mobiles? > >>>>> > >>>>> And obviously it is possible to do KEY and EKEY du9e to the > >>>>> ANS standard under Windows since Rufig actually did that. > >>>>> > >>>>> What's wrong with you guys? > >>>> > >>>> What is wrong with YOU? The issue has been explained clearly > >>>> to you. If you don't like it why not *FIX YOUR SYSTEM* to not > >>>> change the characters assigned to keys? > >>>> > >>>> For the last time, this is *NOT* a Forth problem. It is a Unix > >>>> problem. That and a short between the headphones. > >>>> > >>>> -- > >>>> > >>>> Rick C > >>> It's very easy to solve the problem by using SP-Forth. The issue > >>> was: KEY in GForth isn't ANS standard. > >> > >> You are saying that SP-Forth returns a cntl-H character when > >> backspace is pressed but gForth returns a Del character? Even so, > >> it has to do with the way the process is being handled by Unix. > >> You need to fix the problem in Unix and all will be well. Do you > >> know much about Unix? > >> > >> -- > >> > >> Rick C > > > > I know absolutely nothing about Unix except the confusion with > > backspace and delete, which is a minor problem. > > So far that is the only problem you have made clear. If you don't tell > us what is happening we have no idea how to help you. If it is a > "minor" problem, why are you complaining about it? > > I get that you know nothing of Unix. If you want to learn you can fix > this. > > > > The problem with GForth is that KEY doesn't work due to Forth but due > > to Unix terminals. Since I'm testing to do a pure ANS Forth editor it > > wont work properly on GForth and perhaps not on Unix at all. I didn't > > know that GForth was so "infected" of Unix. > > Are you going to explain to us in what way KEY doesn't work other than > the BS/delete problem? > > > > I have ubuntu on a stick and I have tested it, but I'm glad I haven't > > installed it definitely since Unix seems to be such a meddlesome OS. > > Your language is very inflammatory. If you want to support multiple OS > then maybe you should learn something about them??? You are coming > across like a child throwing a tantrum. Why not discuss the issues with > us and maybe there will be a simple way to deal with this just as others > were able to show you how to use EKEY properly. > > -- > > Rick C You write that I complain about the problem - not the minor problem but the problem that GForth KEY emits escape codes instead of just put a number on the stack - but my only complain is that no one admit this. It is not Forth when KEY do emitting. The inflammatory process is due to the Unix infection...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-28 09:58 +0000 |
| Message-ID | <2017Feb28.105843@mips.complang.tuwien.ac.at> |
| In reply to | #55247 |
lehs <skydda.barnen@gmail.com> writes:
> problem that GForth KEY emits escape codes instead of just put a number on=
> the stack - but my only complain is that no one admit this.=20
>
>It is not Forth when KEY do emitting.=20
Yes, KEY should not emit.
Are you sure that it emits? Or is it the case that KEY just takes the
first char of the escape sequence and, e.g., the text interpreter's
ACCEPT then reads and echos the rest of the escape sequence?
You can test that by running
: foo begin key drop again ; foo
then type away. If you see any output coming from FOO, that's a bug
in Gforth. Please report the platform and Gforth version, what you
did, and what happened, so that we can reproduce and fix it.
- 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-28 02:37 -0800 |
| Message-ID | <b00a014d-ea85-40b1-b60e-83519ba0637d@googlegroups.com> |
| In reply to | #55250 |
Den tisdag 28 februari 2017 kl. 11:06:25 UTC+1 skrev Anton Ertl: > lehs <skydda.barnen@gmail.com> writes: > > problem that GForth KEY emits escape codes instead of just put a number on= > > the stack - but my only complain is that no one admit this.=20 > > > >It is not Forth when KEY do emitting.=20 > > Yes, KEY should not emit. > > Are you sure that it emits? Or is it the case that KEY just takes the > first char of the escape sequence and, e.g., the text interpreter's > ACCEPT then reads and echos the rest of the escape sequence? > > You can test that by running > > : foo begin key drop again ; foo > > then type away. If you see any output coming from FOO, that's a bug > in Gforth. Please report the platform and Gforth version, what you > did, and what happened, so that we can reproduce and fix it. > > - 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/ I admit that your FOO do not emit anything, but <ctrl right arrow> does: KEY ok [1;5C With this GForth construction it's impossible to use <ctrl right arrow> in an editor to step one word forward. I was a bit confused about the emitting, because the real problem is that KEY respond to <ctrl right arrow> but should only respond to a predefined character set and that EKEY does not put raw data on the stack to be interpreted by the application program. Doing an editor in ANS Forth it's not possible to use the <ctrl right/left arrow> if it respond with ESC=27. It looks to me that SP-Forths solution better correspond to the ANS standard.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-28 12:46 +0000 |
| Message-ID | <2017Feb28.134655@mips.complang.tuwien.ac.at> |
| In reply to | #55252 |
lehs <skydda.barnen@gmail.com> writes:
>Den tisdag 28 februari 2017 kl. 11:06:25 UTC+1 skrev Anton Ertl:
>I admit that your FOO do not emit anything, but <ctrl right arrow> does:
>KEY ok
>[1;5C
The xterms that I use also produce <esc>[1;5C for Ctrl-<right arrow>.
Gforth 0.6.2 does not know this escape sequence, but Gforth 0.7 and
the current development version do, and on them EKEY produces the same
result as K-CTRL-MASK K-RIGHT OR. So my guess is that this problem
can be fixed by upgrading 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: 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-28 05:01 -0800 |
| Message-ID | <dc0e4f3c-093c-4da9-92de-f4c12270ef8d@googlegroups.com> |
| In reply to | #55268 |
Den tisdag 28 februari 2017 kl. 13:53:07 UTC+1 skrev Anton Ertl: > lehs <skydda.barnen@gmail.com> writes: > >Den tisdag 28 februari 2017 kl. 11:06:25 UTC+1 skrev Anton Ertl: > >I admit that your FOO do not emit anything, but <ctrl right arrow> does: > >KEY ok > >[1;5C > > The xterms that I use also produce <esc>[1;5C for Ctrl-<right arrow>. > Gforth 0.6.2 does not know this escape sequence, but Gforth 0.7 and > the current development version do, and on them EKEY produces the same > result as K-CTRL-MASK K-RIGHT OR. So my guess is that this problem > can be fixed by upgrading 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: http://www.forth200x.org/forth200x.html > EuroForth 2016: http://www.euroforth.org/ef16/ Whatever. Windows SP-Forth acts the way I expect from the ANS document and I really hope there are no native Forth acting significantly different from that.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-02-28 12:46 +0100 |
| Message-ID | <o93nvj$ra7$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #55247 |
In article <1625fce4-5a8f-43a1-a249-1dedcef01703@googlegroups.com>, lehs <skydda.barnen@gmail.com> wrote: > >You write that I complain about the problem - not the minor problem but the= > problem that GForth KEY emits escape codes instead of just put a number on= > the stack - but my only complain is that no one admit this.=20 Really this is silly talk. I can hook up a Linux system with 20 VT220 terminals for all the children in my class. Each can run gforth, provided I have two cards with 16 serial lines. Now the VT220 (maybe not the DEC ones, but certain clones) have the property that you can have keyboard macro's. So pressing <SHIFT function key one> sends "welcome" , the favorite password you always use. That is 7 characters instead of the ascii code for <shift function key one>. Oops, there is no ascii code for <shift function key one>. Now you expect gforth to translate this "welcome" to an EKEY meaning <SHIFT function key one>. That is just plain unreasonable. If she'd succeed, it would be at most for this terminal type. There are also cursor keys. There is no ascii code for cursor up. Cursor keys cannot be configured, but what should cursor up send? Helpfully the terminal sends an ascii escape sequence. If it receives such a sequence ... the cursor goes up. (Brilliant!). (This escape sequence was original by DEC: VT50 --> VT100 --> VT200 --> ASCII escape ) Bottom line is that EKEY only makes sense in combination with a specified particular keyboard. It is a fault of the standard if it suggest a degree of portability beyond that. > >It is not Forth when KEY do emitting.=20 > >The inflammatory process is due to the Unix infection... MS-Windows only works on one computer, the so called IBM PC. They have two layouts XT and AT. XT is nearly extinct. That is easy. Unix has to cope with a bazillion different type writers and glass teletypes and now xterminals that can even change their font-type. Brilliant minds have succeeded in capturing essential features in a database ( called infocom) and creating a workable situation. This is done through a portability layer: the curses library (now ncurses), so now you can play hack on any terminal. That is "getting the job done". 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 | Mikael Nordman <oh2aun@gmail.com> |
|---|---|
| Date | 2017-02-28 03:52 -0800 |
| Message-ID | <6bc4d1c0-0296-4cd6-86fe-781161a8c08d@googlegroups.com> |
| In reply to | #55262 |
On Tuesday, February 28, 2017 at 1:47:25 PM UTC+2, Albert van der Horst wrote: > In article <1625fce4-5a8f-43a1-a249-1dedcef01703@googlegroups.com>, > lehs <skydda.barnen@gmail.com> wrote: > > > >You write that I complain about the problem - not the minor problem but the= > > problem that GForth KEY emits escape codes instead of just put a number on= > > the stack - but my only complain is that no one admit this.=20 Try this: : keychars begin key . again ; That will show you exactly what you need to analyze in your editor in order to it working.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-28 04:10 -0800 |
| Message-ID | <4af0d866-36ac-4e4f-bea0-63ecf97f5c14@googlegroups.com> |
| In reply to | #55264 |
Den tisdag 28 februari 2017 kl. 12:52:21 UTC+1 skrev Mikael Nordman: > On Tuesday, February 28, 2017 at 1:47:25 PM UTC+2, Albert van der Horst wrote: > > In article <1625fce4-5a8f-43a1-a249-1dedcef01703@googlegroups.com>, > > lehs <skydda.barnen@gmail.com> wrote: > > > > > >You write that I complain about the problem - not the minor problem but the= > > > problem that GForth KEY emits escape codes instead of just put a number on= > > > the stack - but my only complain is that no one admit this.=20 > > Try this: > > : keychars begin key . again ; > > That will show you exactly what you need to analyze in your editor in order to it working. Yes, I was confused by the escape codes, which also is a minor problem. The real problem is that <ctrl right arrow> at all is accepted as "a member of the implementation-defined character set" and that <ctrl right arrow> and <ctrl left arrow> gives the same values (27).
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-28 05:48 -0800 |
| Message-ID | <f5340c92-02dc-4b69-92dc-612a08e0ccca@googlegroups.com> |
| In reply to | #55232 |
I want to add that I love 64 bit GForth for Windows and GForth for Androids, letting me use my system BigZ anywhere. It seems more easy to maintain portability for all arithmetics than for KEY and EKEY. https://forthmath.blogspot.se
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-28 10:07 +0000 |
| Message-ID | <2017Feb28.110726@mips.complang.tuwien.ac.at> |
| In reply to | #55218 |
lehs <skydda.barnen@gmail.com> writes:
>It's very easy to solve the problem by using SP-Forth.
Hmm, in SP-Forth 4.20 KEY just returns 0 without waiting for input. I
have no idea how you want to write an editor with that. In an earlier
version (apparently from 2005), KEY waits for input (until I type
<Enter>), and when I type something in, it is echoed, and, after I
type <Enter> KEY puts the right result on the stack. In that version,
when I do
KEY . KEY . KEY . KEY .
and I type in <Cursor-Up>x<Enter>, I get "27 91 65 120", like with
other Forth systems.
- 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-28 02:42 -0800 |
| Message-ID | <23ab0548-35c3-4c69-a05b-6408ae27ea64@googlegroups.com> |
| In reply to | #55251 |
Den tisdag 28 februari 2017 kl. 11:23:12 UTC+1 skrev Anton Ertl: > lehs <skydda.barnen@gmail.com> writes: > >It's very easy to solve the problem by using SP-Forth. > > Hmm, in SP-Forth 4.20 KEY just returns 0 without waiting for input. I > have no idea how you want to write an editor with that. In an earlier > version (apparently from 2005), KEY waits for input (until I type > <Enter>), and when I type something in, it is echoed, and, after I > type <Enter> KEY puts the right result on the stack. In that version, > when I do > > KEY . KEY . KEY . KEY . > > and I type in <Cursor-Up>x<Enter>, I get "27 91 65 120", like with > other Forth systems. > > - 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/ I can't tell about SP-Forth for Unix really, but it would really surprise me if Rufig published a version where KEY didn't wait for a key press. In Windows SP-Forth works very nice and *fast*.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-02-28 02:44 -0800 |
| Message-ID | <bc83aad9-3aaf-492a-a182-6ce55cc5158e@googlegroups.com> |
| In reply to | #55251 |
On Tuesday, 28 February 2017 10:23:12 UTC, Anton Ertl wrote: > lehs <skydda.barnen@gmail.com> writes: > >It's very easy to solve the problem by using SP-Forth. > > Hmm, in SP-Forth 4.20 KEY just returns 0 without waiting for input. I > have no idea how you want to write an editor with that. In an earlier > version (apparently from 2005), KEY waits for input (until I type > <Enter>), and when I type something in, it is echoed, and, after I > type <Enter> KEY puts the right result on the stack. In that version, > when I do > > KEY . KEY . KEY . KEY . > > and I type in <Cursor-Up>x<Enter>, I get "27 91 65 120", like with > other Forth systems. > > - 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/ Neither spFprth or GForth sounds correct to me. KEY should WAIT for a keypress. When a kepyress arrives, place it on the stack and return. KEY? should *not* wait for a keypress. It should poll and return. If no key press is available, push 0. If a keypress is available, push the ascii code. Forths running on desktops are going to be at the mercy of the underlying OS when control/alt etc keys are used. It's highly likely that multiple ascii codes would come back. A state machine should be constructed using KEY?
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-02-28 12:13 +0100 |
| Message-ID | <17halk639ri7y.xolsh7hp0jfq$.dlg@40tude.net> |
| In reply to | #55254 |
Op Tue, 28 Feb 2017 02:44:14 -0800 (PST) schreef Mark Wills: > On Tuesday, 28 February 2017 10:23:12 UTC, Anton Ertl wrote: >> lehs <skydda.barnen@gmail.com> writes: >>>It's very easy to solve the problem by using SP-Forth. >> >> Hmm, in SP-Forth 4.20 KEY just returns 0 without waiting for input. I >> have no idea how you want to write an editor with that. In an earlier >> version (apparently from 2005), KEY waits for input (until I type >> <Enter>), and when I type something in, it is echoed, and, after I >> type <Enter> KEY puts the right result on the stack. In that version, >> when I do >> >> KEY . KEY . KEY . KEY . >> >> and I type in <Cursor-Up>x<Enter>, I get "27 91 65 120", like with >> other Forth systems. >> >> - 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/ > > Neither spFprth or GForth sounds correct to me. > > KEY should WAIT for a keypress. When a kepyress arrives, place it on the > stack and return. > > KEY? should *not* wait for a keypress. It should poll and return. If > no key press is available, push 0. If a keypress is available, push > the ascii code. KEY? delivers only FALSE or TRUE. The next KEY pushes the ASCII code. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-02-28 05:10 -0800 |
| Message-ID | <13874be1-d2a0-41c3-ab60-219203782ebe@googlegroups.com> |
| In reply to | #55256 |
On Tuesday, 28 February 2017 11:13:40 UTC, Coos Haak wrote: > Op Tue, 28 Feb 2017 02:44:14 -0800 (PST) schreef Mark Wills: > > > On Tuesday, 28 February 2017 10:23:12 UTC, Anton Ertl wrote: > >> lehs <skydda.barnen@gmail.com> writes: > >>>It's very easy to solve the problem by using SP-Forth. > >> > >> Hmm, in SP-Forth 4.20 KEY just returns 0 without waiting for input. I > >> have no idea how you want to write an editor with that. In an earlier > >> version (apparently from 2005), KEY waits for input (until I type > >> <Enter>), and when I type something in, it is echoed, and, after I > >> type <Enter> KEY puts the right result on the stack. In that version, > >> when I do > >> > >> KEY . KEY . KEY . KEY . > >> > >> and I type in <Cursor-Up>x<Enter>, I get "27 91 65 120", like with > >> other Forth systems. > >> > >> - 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/ > > > > Neither spFprth or GForth sounds correct to me. > > > > KEY should WAIT for a keypress. When a kepyress arrives, place it on the > > stack and return. > > > > KEY? should *not* wait for a keypress. It should poll and return. If > > no key press is available, push 0. If a keypress is available, push > > the ascii code. > KEY? delivers only FALSE or TRUE. The next KEY pushes the ASCII code. > > groet Coos Ah yes, you're right! Bit rot ;-)
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-02-28 12:12 +0000 |
| Message-ID | <MPG.331f79798fa304d29896f4@news.virginmedia.com> |
| In reply to | #55251 |
I have to say .... bored now. I do have a couple of questions 1. does anyone have a list of forths that claim to be standard compatible (any of the standards) and those that don't. 2. does anyone have a list that claim standards compatibility with variations clearly listed that are fully documented? and one suggestion fot the thread: http://forth-standard.org/standard/core/KEY i dont see any issues (although I'd personally drop the clause : "...and those events are subsequently unavailable. " as being unnecesarily restrictive, without further explanation) The link to the graphis characters further clarifies and demonstrates the good use of standards I believe. also let's not forget - no operating system returns either a BS or a DEL What they return is a bunch of bits you can interpet as an ascii code They don't become DEL or BS until you use them as such. If you dont like the use just trap them and recode. It's forth - not rocket science. (OK ... well... only sometimes rocket science) -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-27 13:51 -0800 |
| Message-ID | <4a50e2dc-ca4c-4744-b139-f4f6a4e88672@googlegroups.com> |
| In reply to | #55206 |
Den måndag 27 februari 2017 kl. 21:50:22 UTC+1 skrev Coos Haak: > Op Mon, 27 Feb 2017 08:58:38 -0800 (PST) schreef lehs: > > > Den måndag 27 februari 2017 kl. 11:35:16 UTC+1 skrev lehs: > <snip> > > Unfortunately I can't load Win32Forth no longer. > > If you don't use Norton Securtity, you can use Win32Forth > on both 32 bit and 64 bit Windows. > > groet Coos I use Avg and can't. On my old laptop it worked fine, but now it stop loading after a while.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-27 15:38 +0000 |
| Message-ID | <2017Feb27.163840@mips.complang.tuwien.ac.at> |
| In reply to | #55164 |
lehs <skydda.barnen@gmail.com> writes:
>The DPANS document says:
>
>"Receive one character char, a member of the implementation-defined character set. Keyboard events that do not correspond to such characters are discarded until a valid character is received, and those events are subsequently unavailable.
>
>All standard characters can be received. Characters received by KEY are not displayed."
>
>GForth KEY do not discard 'arrow up' but return 27 on the stack and emits '[A'. That might be good but is it really ANS Forth?
A Forth system that talks to a VT100-compatible terminal has no way to
know whether the user pressed Cursor-Up or the sequence <ESC>[A (well,
Gforth's EKEY tries to differentiate between these cases by timing,
but thanks to network lags and macro keyboards that is not a 100%
reliable way).
And indeed, looking at Gforth, SwiftForth, VFX Forth, and bigForth for
Linux, when I do
key . key . key . key .
and then press Cursor-up and then x, all of them output
27 91 65 120
I also tried SP-Forth 4.20 for Linux, but its KEY just returns 0
without waiting for a keypress; and EKEY just gives an error.
>Words like KEY and EMIT must be exactly the same on any system.
Apart from SP-Forth, the systems I tried behaved the same way.
> Else portability is an illusion.
No, behaving exactly the same is not necessary for portability. E.g.,
CELLS does not behave the same way on 32-bit and 64-bit systems, and
yet it is possible to write Forth programs that port between 32-bit
and 64-bit systems, the the different behaviour of CELLS is a key part
in that portability.
Concerning KEY, it is a word for getting the raw input, and there are
differences based on where the input is coming from (a terminal, a
keyboard, or some serial port).
For an editor, I would recommend working with EKEY, EKEY>CHAR,
EKEY>FKEY, and the K-... words; and always provide an alternative to
the special keys for cases where the keyboard does not have the
special keys, or they do not work as expected.
- 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]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web