Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #55002 > unrolled thread

Inconsequent EKEY values in GForth

Back to article view | Back to comp.lang.forth

Contents

  Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-19 02:52 -0800
    Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-21 17:16 -0500
      Re: Inconsequent EKEY values in GForth Julian Fondren <julian.fondren@gmail.com> - 2017-02-21 14:26 -0800
      Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-21 23:01 -0800
      Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-21 23:50 -0800
        Re: Inconsequent EKEY values in GForth Paul Rubin <no.email@nospam.invalid> - 2017-02-22 00:40 -0800
          Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 00:44 -0800
            Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 00:48 -0800
            Re: Inconsequent EKEY values in GForth Paul Rubin <no.email@nospam.invalid> - 2017-02-22 00:51 -0800
              Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 00:54 -0800
              Re: Inconsequent EKEY values in GForth minforth@arcor.de - 2017-02-22 02:11 -0800
                Re: Inconsequent EKEY values in GForth Paul Rubin <no.email@nospam.invalid> - 2017-02-22 13:46 -0800
                  Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-22 17:04 -0500
                    Re: Inconsequent EKEY values in GForth minforth@arcor.de - 2017-02-23 04:21 -0800
                  Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-23 05:51 -0800
                    Re: Inconsequent EKEY values in GForth Julian Fondren <ayrnieu@gmail.com> - 2017-02-23 06:02 -0800
                      Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-23 06:10 -0800
                        Re: Inconsequent EKEY values in GForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-23 15:45 +0000
                  Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-23 07:07 -0800
      Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 04:25 -0800
        Re: Inconsequent EKEY values in GForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-22 14:22 +0100
          Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 11:16 -0800
        Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-22 11:44 -0800
        Re: Inconsequent EKEY values in GForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-23 16:21 +0000
          Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-24 05:04 -0800
            Re: Inconsequent EKEY values in GForth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-24 12:27 -1000
              Re: Inconsequent EKEY values in GForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-25 12:51 +0100
            Re: Inconsequent EKEY values in GForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-25 16:37 +0000
        Re: Inconsequent EKEY values in GForth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-03-12 04:20 +0000
      Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-25 05:14 -0800
        Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-25 16:24 -0500
          Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-25 18:48 -0800
            Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-25 23:41 -0500
              Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-26 00:48 -0800
                Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-26 03:13 -0800
                  Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-26 15:27 -0500
                    Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-26 23:39 -0800
                  Re: Inconsequent EKEY values in GForth peter.m.falth@gmail.com - 2017-02-26 14:42 -0800
                    Re: Inconsequent EKEY values in GForth rickman <gnuarm@gmail.com> - 2017-02-26 18:20 -0500
                    Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-26 23:43 -0800
                      Re: Inconsequent EKEY values in GForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-27 13:03 +0100
                        Re: Inconsequent EKEY values in GForth lehs <skydda.barnen@gmail.com> - 2017-02-27 04:22 -0800
                          Re: Inconsequent EKEY values in GForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-27 13:31 +0100
    Re: Inconsequent EKEY values in GForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-23 16:27 +0000
    Re: Inconsequent EKEY values in GForth Bernd Paysan <bernd@net2o.de> - 2017-03-12 00:36 +0000

Page 1 of 3  [1] 2 3  Next page →

#55002 — Inconsequent EKEY values in GForth

EKEY for return gives 10 in the Android version but 13 in the Windows versions. :)

I'll try to make a simple but highly extendable editor in ANS-Forth...

[toc] | [next] | [standalone]

#55038

On 2/19/2017 5:52 AM, lehs wrote:
> EKEY for return gives 10 in the Android version but 13 in the Windows versions. :)
>
> I'll try to make a simple but highly extendable editor in ANS-Forth...

In the Windows version are you sure it doesn't return 13 *and* 10 in 
that order?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#55039

On Tuesday, February 21, 2017 at 4:16:42 PM UTC-6, rickman wrote:
> On 2/19/2017 5:52 AM, lehs wrote:
> > EKEY for return gives 10 in the Android version but 13 in the Windows versions. :)
> >
> > I'll try to make a simple but highly extendable editor in ANS-Forth...

Doesn't look like this post made it as far as Google Groups.

>
> In the Windows version are you sure it doesn't return 13 *and* 10 in
> that order?
>

It's EKEY , so it *should* be returning a single value for a single key, and
return is a pretty obvious key for EKEY to consider.

The following page has VK_RETURN at 13:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx

[toc] | [prev] | [next] | [standalone]

#55044

Den tisdag 21 februari 2017 kl. 23:16:42 UTC+1 skrev rickman:
> On 2/19/2017 5:52 AM, lehs wrote:
> > EKEY for return gives 10 in the Android version but 13 in the Windows versions. :)
> >
> > I'll try to make a simple but highly extendable editor in ANS-Forth...
> 
> In the Windows version are you sure it doesn't return 13 *and* 10 in 
> that order?
> 
> -- 
> 
> Rick C

OK! I wrote this post and erased it because I wasn't sure about how different keyboards interacted. If it maybe depended on that?

In Windows EKEY return just one value, 13, on my system. But such in-consequences are easy to manage. In SP-Forth EKEY return different values for each key, even for shift, ctrl and alt, which make a greater problem for compatibility.

[toc] | [prev] | [next] | [standalone]

#55045

By the way, my work with the editor is on GitHub:

https://github.com/Lehs/Simple-editor-in-ANS-Forth

[toc] | [prev] | [next] | [standalone]

#55046

lehs <skydda.barnen@gmail.com> writes:
> https://github.com/Lehs/Simple-editor-in-ANS-Forth

Looks cool, needs a way to redraw the screen, maybe on ^L.

[toc] | [prev] | [next] | [standalone]

#55047

Den onsdag 22 februari 2017 kl. 09:40:36 UTC+1 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > https://github.com/Lehs/Simple-editor-in-ANS-Forth
> 
> Looks cool, needs a way to redraw the screen, maybe on ^L.

I use CTRL E for exit. 

Unfortunately there are some errors and I just corrected one of them. When I have implemented LOAD and SAVE, then I regard SED to be safe enough to be used.

[toc] | [prev] | [next] | [standalone]

#55048

Den onsdag 22 februari 2017 kl. 09:44:36 UTC+1 skrev lehs:
> Den onsdag 22 februari 2017 kl. 09:40:36 UTC+1 skrev Paul Rubin:
> > lehs <skydda.barnen@gmail.com> writes:
> > > https://github.com/Lehs/Simple-editor-in-ANS-Forth
> > 
> > Looks cool, needs a way to redraw the screen, maybe on ^L.
> 
> I use CTRL E for exit. 
> 
> Unfortunately there are some errors and I just corrected one of them. When I have implemented LOAD and SAVE, then I regard SED to be safe enough to be used.

I misread your post. My intention is that redrawing should be automatic, but I haven't tried it yet.

[toc] | [prev] | [next] | [standalone]

#55049

lehs <skydda.barnen@gmail.com> writes:
>> Looks cool, needs a way to redraw the screen, maybe on ^L.
> I use CTRL E for exit. 

Yes, I figured that out for the code.  I'm suggesting adding a way to
redraw the screen if the contents get messed up somehow, for example
by suspending Forth with ^Z and then resuming.

> Unfortunately there are some errors and I just corrected one of
> them. When I have implemented LOAD and SAVE, then I regard SED to be
> safe enough to be used.

I didn't notice that you had LOAD and SAVE.  I guess you just added
them, so I'll download a new version.

This currently seems like a hybrid between a file editor and a block
editor.  Not sure how that should play out going forward.

[toc] | [prev] | [next] | [standalone]

#55050

Den onsdag 22 februari 2017 kl. 09:51:19 UTC+1 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> >> Looks cool, needs a way to redraw the screen, maybe on ^L.
> > I use CTRL E for exit. 
> 
> Yes, I figured that out for the code.  I'm suggesting adding a way to
> redraw the screen if the contents get messed up somehow, for example
> by suspending Forth with ^Z and then resuming.
> 
> > Unfortunately there are some errors and I just corrected one of
> > them. When I have implemented LOAD and SAVE, then I regard SED to be
> > safe enough to be used.
> 
> I didn't notice that you had LOAD and SAVE.  I guess you just added
> them, so I'll download a new version.
> 
> This currently seems like a hybrid between a file editor and a block
> editor.  Not sure how that should play out going forward.

There is no "LOAD/OPEN" or "SAVE" yet, but your idea with a refresh key isn't bad at all. Will soon be done.

[toc] | [prev] | [next] | [standalone]

#55051

Am Mittwoch, 22. Februar 2017 09:51:19 UTC+1 schrieb Paul Rubin:
> This currently seems like a hybrid between a file editor and a block
> editor.  Not sure how that should play out going forward.

In a pure desktop system any good file editor would do of course.

But in umbilical configurations a compact editor for target-resident sources makes sense. However the UI must fit the configuration too, particularly considering possible slow reaction times over the link. 

[toc] | [prev] | [next] | [standalone]

#55060

minforth@arcor.de writes:

> But in umbilical configurations a compact editor for target-resident
> sources makes sense.

This editor uses a 0.5MB ram buffer to hold the file being edited.  Of
course the buffer could be made smaller but it's still not a great
approach for a ram limited target.

[toc] | [prev] | [next] | [standalone]

#55061

On 2/22/2017 4:46 PM, Paul Rubin wrote:
> minforth@arcor.de writes:
>
>> But in umbilical configurations a compact editor for target-resident
>> sources makes sense.
>
> This editor uses a 0.5MB ram buffer to hold the file being edited.  Of
> course the buffer could be made smaller but it's still not a great
> approach for a ram limited target.

I guess I'm a bit confused.  I thought for an umbilical configuration 
everything was done on the host and only code was downloaded to the 
target.  Why try to support tools and storage on the target when there 
is a host with much more in the way of resources of all types?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#55064

Am Mittwoch, 22. Februar 2017 23:04:06 UTC+1 schrieb rickman:
> On 2/22/2017 4:46 PM, Paul Rubin wrote:
> > minforth@arcor.de writes:
> >
> >> But in umbilical configurations a compact editor for target-resident
> >> sources makes sense.
> >
> > This editor uses a 0.5MB ram buffer to hold the file being edited.  Of
> > course the buffer could be made smaller but it's still not a great
> > approach for a ram limited target.
> 
> I guess I'm a bit confused.  I thought for an umbilical configuration 
> everything was done on the host and only code was downloaded to the 
> target.  Why try to support tools and storage on the target when there 
> is a host with much more in the way of resources of all types?
> 
> -- 
> 
> Rick C

You are right for most cases e.g. for cross-compiling on the host and downloading binaries to the target.

We made good experience with having local debug monitors (e.g. live hex dumps of controller memory ranges) and remotely editable parameter tables in blocks.

[toc] | [prev] | [next] | [standalone]

#55065

Den onsdag 22 februari 2017 kl. 22:46:26 UTC+1 skrev Paul Rubin:
> minforth@arcor.de writes:
> 
> > But in umbilical configurations a compact editor for target-resident
> > sources makes sense.
> 
> This editor uses a 0.5MB ram buffer to hold the file being edited.  Of
> course the buffer could be made smaller but it's still not a great
> approach for a ram limited target.

Well, you're talking of things I don't understand. 

My purpose was not to code an editor for small systems, but to code a functional editor to be formed as I want a Forth editor to be. Simple to code, simple to understand, simple to extend. From what I've seen so far I'm convinced that this is going to be my favorite.

It's only an embryo but saving and opening is now included:

https://github.com/Lehs/Simple-editor-in-ANS-Forth

I must admit I'm disappointed on EKEY in GForth. The system used in SP_Forth is much more general and useful: each key has one code. In GForth 64 bit you can't even use all control codes:

ctrl a   1
ctrl b   2
ctrl c   - 
ctrl d   4
ctrl e   5
ctrl f   6
ctrl g   7
ctrl h   8
ctrl i   9
ctrl j  10
ctrl k  11
ctrl l  12
ctrl m  13
ctrl n  14
ctrl o  15
ctrl p  16
ctrl q   -
ctrl r  18
ctrl s   -
ctrl t  20
ctrl u  21
ctrl v  22
ctrl w  23
ctrl x  24
ctrl y  25
ctrl z   -

[toc] | [prev] | [next] | [standalone]

#55066

On Thursday, February 23, 2017 at 7:51:12 AM UTC-6, lehs wrote:
> I must admit I'm disappointed on EKEY in GForth. The system used in SP_Forth is much more general and useful: each key has one code. In GForth 64 bit you can't even use all control codes:

Unix terminals intercept the following for their use:

> ctrl c   - 

Send the interrupt signal.

> ctrl q   -

Resume display updates.

> ctrl s   -

Freeze display updates.

> ctrl z   -

Stop the foreground process and put it in the background.

All useful for

. misbehaving programs
. terminals without scrollbars
. environments with no better job control

With ioctl calls you may be able to tell the terminal that
you'll handle most of these yourself.

[toc] | [prev] | [next] | [standalone]

#55067

Den torsdag 23 februari 2017 kl. 15:02:19 UTC+1 skrev Julian Fondren:
> On Thursday, February 23, 2017 at 7:51:12 AM UTC-6, lehs wrote:
> > I must admit I'm disappointed on EKEY in GForth. The system used in SP_Forth is much more general and useful: each key has one code. In GForth 64 bit you can't even use all control codes:
> 
> Unix terminals intercept the following for their use:
> 
> > ctrl c   - 
> 
> Send the interrupt signal.
> 
> > ctrl q   -
> 
> Resume display updates.
> 
> > ctrl s   -
> 
> Freeze display updates.
> 
> > ctrl z   -
> 
> Stop the foreground process and put it in the background.
> 
> All useful for
> 
> . misbehaving programs
> . terminals without scrollbars
> . environments with no better job control
> 
> With ioctl calls you may be able to tell the terminal that
> you'll handle most of these yourself.

OK, but the purpose of EKEY should be to be able to do whatever you want, in my opinion. Else there is KEY to be used in a standard way.

In SP-Forth all the (single stroke) keys has a code and one could use that for any purpose, while designing a SPECIAL-KEY in detail.

[toc] | [prev] | [next] | [standalone]

#55070

lehs <skydda.barnen@gmail.com> writes:
>> With ioctl calls you may be able to tell the terminal that
>> you'll handle most of these yourself.
>
>OK, but the purpose of EKEY should be to be able to do whatever you want, in my opinion.

The event never reaches Gforth (at least not as keyboard event) and
therefore EKEY.

Of course, Gforth could set up the terminal so that it sees these
events.  However, there are different kinds of programs: for most,
treating these keys in the conventional way is the most practical
approach: you want to be able to interrupt a program that takes a long
time, and to use flow-control if it outputs a lot of stuff (and
scrollback in windows is often limited).  Therefore, IMO it's best if
Gforth does not change the terminal settings, and if those
applications that want different settings do that setup themselves.

- 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]

#55068

Den onsdag 22 februari 2017 kl. 22:46:26 UTC+1 skrev Paul Rubin:
> minforth@arcor.de writes:
> 
> > But in umbilical configurations a compact editor for target-resident
> > sources makes sense.
> 
> This editor uses a 0.5MB ram buffer to hold the file being edited.  Of
> course the buffer could be made smaller but it's still not a great
> approach for a ram limited target.

Thinking of it, it might be possible to emulate the buffer with the Forth kind of virtual memory..?

[toc] | [prev] | [next] | [standalone]

#55054

There is an other problem with EKEY in GForth:

32-bit Windows makes no difference of e.g. 'right arrow' and 'ctrl right arrow'. Bad, since 'ctrl right arrow' is used for 'next word'.

64-bit Windows makes a bad difference, since 'ctrl right arrow' gives one number on the stack and emit the code '[1;5C', making it totally impossible in my editor.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web