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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-02 15:34 +0000 |
| Message-ID | <2017Mar2.163400@mips.complang.tuwien.ac.at> |
| In reply to | #55324 |
rickman <gnuarm@gmail.com> writes:
>On 3/1/2017 3:50 AM, Anton Ertl wrote:
>> The ASCII code DEL (all bits set) comes from paper tape and card
>> punchers: If you mistyped, you typed DEL, and it would punch across
>> the mistyped character, and the character would be overwritten by DEL.
>> When reading the card/tape, any encountered DEL would be ignored.
>
>Wouldn't you first need to backspace to reposition the tape?
One source I read said that you had to press the repositioning key and
then the DEL key. But given that it does not make sense to punch DEL
without repositioning, I expect that there were punchers that
repositioned automatically when you punched DEL.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-01 18:09 +0000 |
| Message-ID | <2017Mar1.190901@mips.complang.tuwien.ac.at> |
| In reply to | #55282 |
rickman <gnuarm@gmail.com> writes:
>On 2/28/2017 4:02 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> In Linux it is not uncommon to use
>>> key mapping that swaps Delete and Backspace.
>>
>> Swapping is unusual. I find that my <Backspace> key produces a DEL
>> character, and my <Del> key produces an Escape sequence.
...
>Your example above shows what would be considered non-standard in many
>apps. A backspace key normally is considered to generate a cntl-H
>character.
On what do you base this claim?
> Why on earth does it make sense to produce a DEL (delete)?
Some programs (e.g., Emacs) have another use for Ctrl-H than
delete-backwards.
>>> I don't know why these key remappings are not uncommon under Unix.
>>
>> My guess is that there were terminals where <Backspace> produced BS
>> and there were terminals where it produced DEL.
>
>Terminals??? You mean separate hardware connected over a serial port?
Yes.
>I've never seen one that sent anything other than a cntl-H from the
>backspace key and a DEL from the delete key (if it had one).
Supposedly the VT220 produced DEL from the <x| key (which is in the
position where the Backspace key is on a modern PC keyboard). The
Linux console produced DEL for the Backspace key for this reason, and
eventually xterm and the rest of the applications followed, at least
in the Linux ecosystem. I don't know if other Unixes have reached
that state yet, or are still in configuration mess state.
>The swapping was *not* done in the program. I believe it was in the
>terminal settings of the window the program was running in.
There was a configuration mess everywhere: Applications could be
configured to use either BS or DEL for a function, and terminal
emulators could be configured to produce BS or DEL for various keys,
etc.
- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-01 14:55 -0500 |
| Message-ID | <o978s8$9b7$1@dont-email.me> |
| In reply to | #55309 |
On 3/1/2017 1:09 PM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 2/28/2017 4:02 AM, Anton Ertl wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> In Linux it is not uncommon to use >>>> key mapping that swaps Delete and Backspace. >>> >>> Swapping is unusual. I find that my <Backspace> key produces a DEL >>> character, and my <Del> key produces an Escape sequence. > ... >> Your example above shows what would be considered non-standard in many >> apps. A backspace key normally is considered to generate a cntl-H >> character. > > On what do you base this claim? > >> Why on earth does it make sense to produce a DEL (delete)? > > Some programs (e.g., Emacs) have another use for Ctrl-H than > delete-backwards. > >>>> I don't know why these key remappings are not uncommon under Unix. >>> >>> My guess is that there were terminals where <Backspace> produced BS >>> and there were terminals where it produced DEL. >> >> Terminals??? You mean separate hardware connected over a serial port? > > Yes. > >> I've never seen one that sent anything other than a cntl-H from the >> backspace key and a DEL from the delete key (if it had one). > > Supposedly the VT220 produced DEL from the <x| key (which is in the > position where the Backspace key is on a modern PC keyboard). The > Linux console produced DEL for the Backspace key for this reason, and > eventually xterm and the rest of the applications followed, at least > in the Linux ecosystem. I don't know if other Unixes have reached > that state yet, or are still in configuration mess state. Yes, I did some digging and found the VT220 backspace key *does* produce a DEL character, but that character would be interpreted as a backspace. The Delete key produced an escape sequence that performed a delete function. Can they make it any more complicated? >> The swapping was *not* done in the program. I believe it was in the >> terminal settings of the window the program was running in. > > There was a configuration mess everywhere: Applications could be > configured to use either BS or DEL for a function, and terminal > emulators could be configured to produce BS or DEL for various keys, > etc. Yeah, and lehs seems to be unhappy with it. :( -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-03-01 21:28 -0800 |
| Message-ID | <d43a3817-2ac9-4aad-b640-ee1f7d7863f4@googlegroups.com> |
| In reply to | #55325 |
Den onsdag 1 mars 2017 kl. 20:55:43 UTC+1 skrev rickman: > On 3/1/2017 1:09 PM, Anton Ertl wrote: > > rickman <gnuarm@gmail.com> writes: > >> On 2/28/2017 4:02 AM, Anton Ertl wrote: > >>> rickman <gnuarm@gmail.com> writes: > >>>> In Linux it is not uncommon to use > >>>> key mapping that swaps Delete and Backspace. > >>> > >>> Swapping is unusual. I find that my <Backspace> key produces a DEL > >>> character, and my <Del> key produces an Escape sequence. > > ... > >> Your example above shows what would be considered non-standard in many > >> apps. A backspace key normally is considered to generate a cntl-H > >> character. > > > > On what do you base this claim? > > > >> Why on earth does it make sense to produce a DEL (delete)? > > > > Some programs (e.g., Emacs) have another use for Ctrl-H than > > delete-backwards. > > > >>>> I don't know why these key remappings are not uncommon under Unix. > >>> > >>> My guess is that there were terminals where <Backspace> produced BS > >>> and there were terminals where it produced DEL. > >> > >> Terminals??? You mean separate hardware connected over a serial port? > > > > Yes. > > > >> I've never seen one that sent anything other than a cntl-H from the > >> backspace key and a DEL from the delete key (if it had one). > > > > Supposedly the VT220 produced DEL from the <x| key (which is in the > > position where the Backspace key is on a modern PC keyboard). The > > Linux console produced DEL for the Backspace key for this reason, and > > eventually xterm and the rest of the applications followed, at least > > in the Linux ecosystem. I don't know if other Unixes have reached > > that state yet, or are still in configuration mess state. > > Yes, I did some digging and found the VT220 backspace key *does* produce > a DEL character, but that character would be interpreted as a backspace. > The Delete key produced an escape sequence that performed a delete > function. Can they make it any more complicated? > > > >> The swapping was *not* done in the program. I believe it was in the > >> terminal settings of the window the program was running in. > > > > There was a configuration mess everywhere: Applications could be > > configured to use either BS or DEL for a function, and terminal > > emulators could be configured to produce BS or DEL for various keys, > > etc. > > Yeah, and lehs seems to be unhappy with it. :( > > -- > > Rick C I have no problem at all with BS and DEL. Most *modern* keyboards and devices (like cellphones) has a button DELETE which isn't an ascii code. The easy way is to let both BS and DEL do backward erase and let DELETE do delete character without moving the cursor on the screen. The real problem is when EKEY doesn't deliver raw data from the keyboard, but instead sometimes gives an escape sequence leaving 27 on topp of stack for a lot of different keys, which is aimed to command different operations. Of course, it very interesting that some Forth is backward compatible with museal terminals. I guess there is a psychological explanation back from the eighties, when personal computers where powerless toys compared with *the real things* used by the big guys. But today even cell phones is faster and bigger than those *real things*.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-03-01 22:23 -0800 |
| Message-ID | <7e5d7494-9a12-4b69-9349-43fd2e5acf5c@googlegroups.com> |
| In reply to | #55358 |
On Wednesday, March 1, 2017 at 11:28:23 PM UTC-6, lehs wrote: > > I have no problem at all with BS and DEL. Most *modern* keyboards and devices (like cellphones) has a button DELETE which isn't an ascii code. The easy way is to let both BS and DEL do backward erase and let DELETE do delete character without moving the cursor on the screen. > ... > Of course, it very interesting that some Forth is backward compatible with museal terminals. I guess there is a psychological explanation back from the eighties, when personal computers where powerless toys compared with *the real things* used by the big guys. But today even cell phones is faster and bigger than those *real things*. You're really persistent about not getting this. If you run Forth in an environment, then Forth is constrained by that environment. "some Forth" do not care about all these museum terminals that you're sneering about as offensively as possible in text--it's the environment that cares about them. "some Forth" are just working as well as they're able with what they're given. You are like a man who can't contain his disgust over the ongoing use of latin characters - didn't the Roman empire fall like, more than a decade ago? Why is stupid gforth persisting in this insane use of some ancient glyphs? People keep trying to draw your attention to the context (it's English, not Forth, that's using these characters) but you keep rebutting: but that's old! Who cares about that?! My *cellphone* has *emoticons*! Well, it's funny, so I really don't mind if you carry on. > The real problem is when EKEY doesn't deliver raw data from the keyboard, but instead sometimes gives an escape sequence leaving 27 on topp of stack for a lot of different keys, which is aimed to command different operations. If that happens then EKEY is never delivering raw data from the keyboard, because the environment doesn't provide this. What EKEY gets, every single time, is a bunch of bytes, some of which are are delivered by the terminal in special codes. You press 'up arrow', and EKEY reads ESC [ A or whatever -- three bytes. Because EKEY knows what this sequence means, it gives you a single code, k-up. When EKEY doesn't know what the sequence means, this is when you're getting your "sometimes gives an escape sequence" behavior. So one real problem is: one Forth's EKEY has a more extensive dictionary of escape sequences than the other. Another may be: you're hoping to use key combinations that don't have escape sequences at all. If you press A B C at the same time for example, you're very unlikely to get a single token from EKEY to represent the chording of these three keys. You'll just get A B and C in some order as separate key-presses. A final problem may be: you are not just using different Forths, but you are also running them in different environments. gforth may come with a cygwin terminal with bash available; wina may run as a windows console appication; maybe your other Forth is running in an interactive win32 application. You have the option of using only those features that are common to the Forths you're targeting. This would be a concern anyway: if your editor relies on arrow keys then it'll have problems if run on a device without them. A very nice game, (Caves of Qud) coded in Unity and running on Windows, Linux, and OSX, still has this serious compatability issue that the developers are still fixing: it assumes too greatly that a numpad is available, but many laptops don't have those keys. Pressing '8' on a laptop without a numpad doesn't give you the behavior in the game as pressing '8' on a numpad would. There are complaints about this. Would you conclude that C# is unportable? You can also augment what's common to an extent. Use EKEY but when EKEY only gives you ESC (27), look for the remainder of an escape sequence and then decode that. It would be nice if EKEY's dictionary were available to be inspected or extended but you can still easily augment it with own decoding when you're concerned that a code may be missed. You can call your new word EKEY and load it before the rest of your editor and things will work just the same as if EKEY knew about those codes to begin with. If your editor will work over a potentially slow network connection, then it should wait to see the rest of an escape sequence even though that seems to be instanteous in local editing. To be clear, I mean the case where the editor is running in Forth on a server somewhere and the user is typing into ssh on his cellphone perhaps. A unix terminal sends ESC[A instead of 'up arrow', ssh sends that bytes through an encrypted channel, packets get dropped and resent maybe, but it works in the end because the editor waits 250ms before deciding that the initial ESC that it sees is really a lone ESC and not the start of a sequence like this one. 90% of my uses of vi are along a network like this.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-03-02 00:21 -0800 |
| Message-ID | <ed092a18-e7f7-46b6-a44e-e7c01cf1a596@googlegroups.com> |
| In reply to | #55361 |
Den torsdag 2 mars 2017 kl. 07:24:01 UTC+1 skrev Julian Fondren: > On Wednesday, March 1, 2017 at 11:28:23 PM UTC-6, lehs wrote: > > > > I have no problem at all with BS and DEL. Most *modern* keyboards and devices (like cellphones) has a button DELETE which isn't an ascii code. The easy way is to let both BS and DEL do backward erase and let DELETE do delete character without moving the cursor on the screen. > > > ... > > Of course, it very interesting that some Forth is backward compatible with museal terminals. I guess there is a psychological explanation back from the eighties, when personal computers where powerless toys compared with *the real things* used by the big guys. But today even cell phones is faster and bigger than those *real things*. > > You're really persistent about not getting this. If you run Forth in > an environment, then Forth is constrained by that environment. "some > Forth" do not care about all these museum terminals that you're > sneering about as offensively as possible in text--it's the > environment that cares about them. "some Forth" are just working as > well as they're able with what they're given. > > You are like a man who can't contain his disgust over the ongoing use > of latin characters - didn't the Roman empire fall like, more than a > decade ago? Why is stupid gforth persisting in this insane use of > some ancient glyphs? People keep trying to draw your attention to the > context (it's English, not Forth, that's using these characters) but > you keep rebutting: but that's old! Who cares about that?! My > *cellphone* has *emoticons*! > > Well, it's funny, so I really don't mind if you carry on. > > > The real problem is when EKEY doesn't deliver raw data from the keyboard, but instead sometimes gives an escape sequence leaving 27 on topp of stack for a lot of different keys, which is aimed to command different operations. > > If that happens then EKEY is never delivering raw data from the > keyboard, because the environment doesn't provide this. What EKEY > gets, every single time, is a bunch of bytes, some of which are are > delivered by the terminal in special codes. You press 'up arrow', and > EKEY reads ESC [ A or whatever -- three bytes. Because EKEY knows what > this sequence means, it gives you a single code, k-up. When EKEY > doesn't know what the sequence means, this is when you're getting your > "sometimes gives an escape sequence" behavior. > > So one real problem is: one Forth's EKEY has a more extensive > dictionary of escape sequences than the other. > > Another may be: you're hoping to use key combinations that don't have > escape sequences at all. If you press A B C at the same time for > example, you're very unlikely to get a single token from EKEY to > represent the chording of these three keys. You'll just get A B and C > in some order as separate key-presses. > > A final problem may be: you are not just using different Forths, but > you are also running them in different environments. gforth may come > with a cygwin terminal with bash available; wina may run as a windows > console appication; maybe your other Forth is running in an > interactive win32 application. > > You have the option of using only those features that are common to > the Forths you're targeting. This would be a concern anyway: if your > editor relies on arrow keys then it'll have problems if run on a > device without them. A very nice game, (Caves of Qud) coded in Unity > and running on Windows, Linux, and OSX, still has this serious > compatability issue that the developers are still fixing: it assumes > too greatly that a numpad is available, but many laptops don't have > those keys. Pressing '8' on a laptop without a numpad doesn't give you > the behavior in the game as pressing '8' on a numpad would. There are > complaints about this. Would you conclude that C# is unportable? > > You can also augment what's common to an extent. Use EKEY but when > EKEY only gives you ESC (27), look for the remainder of an escape > sequence and then decode that. > > It would be nice if EKEY's dictionary were available to be inspected > or extended but you can still easily augment it with own decoding when > you're concerned that a code may be missed. You can call your new word > EKEY and load it before the rest of your editor and things will work > just the same as if EKEY knew about those codes to begin with. > > If your editor will work over a potentially slow network connection, > then it should wait to see the rest of an escape sequence even though > that seems to be instanteous in local editing. To be clear, I mean the > case where the editor is running in Forth on a server somewhere and > the user is typing into ssh on his cellphone perhaps. A unix terminal > sends ESC[A instead of 'up arrow', ssh sends that bytes through an > encrypted channel, packets get dropped and resent maybe, but it works > in the end because the editor waits 250ms before deciding that the > initial ESC that it sees is really a lone ESC and not the start of a > sequence like this one. 90% of my uses of vi are along a network like > this. You don't like me or my postings and maybe I shouldn't even think about trying to be friendly ironic since I'm not native English speaking. No, GForth is not a problem but a gift. I use it every day. My editor is supposed to be ANS Forth and useful and unsophisticated and only for Forth programming. No executable file, just a simple source code, with no need for macros. It is possible to make a totally Forth compatible editor just using ascii characters, printable or ctrl codes, but using the arrows with or without ctrl or shift is an ingrained habit.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-02 01:01 -0800 |
| Message-ID | <87tw7cdpc8.fsf@nightsong.com> |
| In reply to | #55362 |
lehs <skydda.barnen@gmail.com> writes: > It is possible to make a totally Forth compatible editor just using > ascii characters, printable or ctrl codes, but using the arrows with > or without ctrl or shift is an ingrained habit. Maybe the next step is EKEY using termcap/terminfo?
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-03-02 01:30 -0800 |
| Message-ID | <594ff335-3f7d-4252-be87-56406d8536c1@googlegroups.com> |
| In reply to | #55363 |
Den torsdag 2 mars 2017 kl. 10:01:45 UTC+1 skrev Paul Rubin: > lehs <skydda.barnen@gmail.com> writes: > > It is possible to make a totally Forth compatible editor just using > > ascii characters, printable or ctrl codes, but using the arrows with > > or without ctrl or shift is an ingrained habit. > > Maybe the next step is EKEY using termcap/terminfo? Is that portable?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-02 01:46 -0800 |
| Message-ID | <87lgsodn9u.fsf@nightsong.com> |
| In reply to | #55364 |
lehs <skydda.barnen@gmail.com> writes: >> Maybe the next step is EKEY using termcap/terminfo? > Is that portable? At least on *nix systems it's reasonably portable. No idea about Windows. If you want total flexibility maybe you really want keyboard events (up/down and scan code) so you can detect chords etc. That's not very portable and you'd need a bunch of user level code to figure out what everything was. It's probably not very Forthy.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-03-02 02:41 -0800 |
| Message-ID | <abd4c118-2349-4b3c-9f22-e77fb0c465b7@googlegroups.com> |
| In reply to | #55366 |
On Thursday, 2 March 2017 09:46:22 UTC, Paul Rubin wrote: > lehs <skydda.barnen@gmail.com> writes: > >> Maybe the next step is EKEY using termcap/terminfo? > > Is that portable? > > At least on *nix systems it's reasonably portable. No idea about > Windows. > > If you want total flexibility maybe you really want keyboard events > (up/down and scan code) so you can detect chords etc. That's not very > portable and you'd need a bunch of user level code to figure out what > everything was. It's probably not very Forthy. Why not just use different keys for things like cursor up, down, left, right? W A S Z For insert mode CTRL I For delete CTRL D For backspace CTRL B These should return single byte codes, shouldn't they? If they return two byte codes then a simple state machine will suffice. Okay, it's not using the cursor keys etc, but it should make it portable across different machines.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-02 11:01 +0000 |
| Message-ID | <2017Mar2.120157@mips.complang.tuwien.ac.at> |
| In reply to | #55363 |
Paul Rubin <no.email@nospam.invalid> writes:
>lehs <skydda.barnen@gmail.com> writes:
>> It is possible to make a totally Forth compatible editor just using
>> ascii characters, printable or ctrl codes, but using the arrows with
>> or without ctrl or shift is an ingrained habit.
>
>Maybe the next step is EKEY using termcap/terminfo?
When originally implementing EKEY, this looked like the way to go, but
they have complex interfaces, so what we did at first was to just
support the sequences that we found on the Linux console and on xterm,
and it seems that this is good enough.
Surprisingly, they sometimes produced different sequences for the same
key, but as long as they don't produce the same sequence for different
keys, that's no problem. We also added sequences reported for MacOS X
iterm, but otherwise have not received reports of sequences occuring
that we do not recognize. So it seems that standardization of escape
sequences has pretty much succeeded, and going through a configuration
mechanism like termcap/terminfo is no longer necessary.
You can look for "esc-sequence" in
<http://git.savannah.gnu.org/cgit/gforth.git/tree/ekey.fs> to see the
sequences we recognize.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-01 13:48 -0800 |
| Message-ID | <871sughdmj.fsf@nightsong.com> |
| In reply to | #55309 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Supposedly the VT220 produced DEL from the <x| key (which is in the > position where the Backspace key is on a modern PC keyboard). The > Linux console produced DEL for the Backspace key for this reason, Historically DEC OS's used DEL to erase the previous character, while early Unix used DEL as an interrupt character (DEC used control-C). Unix originally used # (pound sign) to erase the previous character, I'm not kidding. Maybe that made sense on printing terminals. My guess is that people thought that was weird so they expected backspace to erase.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-03-04 04:02 +0000 |
| Message-ID | <o9de8s$lq4$1@z-news.wcss.wroc.pl> |
| In reply to | #55246 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> rickman <gnuarm@gmail.com> writes:
> >In Linux it is not uncommon to use
> >key mapping that swaps Delete and Backspace.
>
> Swapping is unusual. I find that my <Backspace> key produces a DEL
> character, and my <Del> key produces an Escape sequence.
>
> >I don't know why these key remappings are not uncommon under Unix.
>
> My guess is that there were terminals where <Backspace> produced BS
> and there were terminals where it produced DEL.
That is true. But Unix for long time is able to do remapping.
AFAICS the real reson for current mapping is Emacs: in Emacs
Ctrl-H is help. This is the same as normal mapping for
<Backspace>. Of course, with such mapping trying to
erase someting would pop Emacs help. In principle one
could bind Emacs help to different code, but than one
would loose mnemonic value of Crl-H. So for Emacs normal
setting was to remap incoming characters so that Crl-H
and <Backspace> were different. Apparently Linux
systems standarized on producing DEL when <Backspace>
is pressed. Other programs adapted to this...
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-04 12:29 +0000 |
| Message-ID | <2017Mar4.132949@mips.complang.tuwien.ac.at> |
| In reply to | #55401 |
antispam@math.uni.wroc.pl writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> My guess is that there were terminals where <Backspace> produced BS
>> and there were terminals where it produced DEL.
>
>That is true. But Unix for long time is able to do remapping.
>AFAICS the real reson for current mapping is Emacs: in Emacs
>Ctrl-H is help. This is the same as normal mapping for
><Backspace>. Of course, with such mapping trying to
>erase someting would pop Emacs help. In principle one
>could bind Emacs help to different code, but than one
>would loose mnemonic value of Crl-H. So for Emacs normal
>setting was to remap incoming characters so that Crl-H
>and <Backspace> were different. Apparently Linux
>systems standarized on producing DEL when <Backspace>
>is pressed. Other programs adapted to this...
A plausible theory, but there is some counterevidence: The Linux
console produced DEL pretty early in the game, probably from the start
(xterm and the rest of the Linux ecosystem switch to that much later),
and Linus Torvalds is not a fan of Emace
<http://marc.info/?l=git&m=122955159617722&w=2>, so it is unlikely
that he chose that setting for Emacs' sake.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-02-28 03:24 -0800 |
| Message-ID | <87fuiyimmu.fsf@nightsong.com> |
| In reply to | #55203 |
rickman <gnuarm@gmail.com> writes: > What you seem to not understand is that a Forth program running under > and OS is at the mercy of the OS. In Linux it is not uncommon to use > key mapping that swaps Delete and Backspace. You can get the raw keyboard events from /dev/console if you're at the console, or see them with xev under X windows. That means you get the actual scan codes when you press and release keys, so your program can interpret them any way it wants.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-28 04:14 -0800 |
| Message-ID | <43b24e74-f509-4d9a-ac81-afbbe6c5ab42@googlegroups.com> |
| In reply to | #55258 |
Den tisdag 28 februari 2017 kl. 12:24:27 UTC+1 skrev Paul Rubin: > rickman <gnuarm@gmail.com> writes: > > What you seem to not understand is that a Forth program running under > > and OS is at the mercy of the OS. In Linux it is not uncommon to use > > key mapping that swaps Delete and Backspace. > > You can get the raw keyboard events from /dev/console if you're at the > console, or see them with xev under X windows. That means you get the > actual scan codes when you press and release keys, so your program can > interpret them any way it wants. Thanks! So it is possible to get raw codes for EKEY both from Windows and from Unix. That is the correct way to implement EKEY. My ignorance made it spin around in my head because of all evasions. :) Then perhaps I will try Unix after all.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-02-27 21:50 +0100 |
| Message-ID | <6lgftqi94w7q$.zyoph9kokgn.dlg@40tude.net> |
| In reply to | #55185 |
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
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-27 13:48 -0800 |
| Message-ID | <5785b08c-b907-4f49-a74c-571f8581c96f@googlegroups.com> |
| In reply to | #55206 |
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 due to the ANS standard under Windows since Rufig actually did that. What's wrong with you guys?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-27 17:41 -0500 |
| Message-ID | <o929qn$k01$1@dont-email.me> |
| In reply to | #55209 |
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 due 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
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-27 15:07 -0800 |
| Message-ID | <a1570cdb-9c19-4f40-8c4a-7fe68cc38e3b@googlegroups.com> |
| In reply to | #55214 |
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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web