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

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

The Forth console and cursor management

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

Contents

  The Forth console and cursor management Alex <alex@rivadpm.com> - 2017-05-23 12:57 +0100
    Re: The Forth console and cursor management Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-23 05:18 -0700
    Re: The Forth console and cursor management anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-23 12:48 +0000
      Re: The Forth console and cursor management Alex <alex@rivadpm.com> - 2017-05-23 15:45 +0100
      Re: The Forth console and cursor management albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-23 20:48 +0200
        Re: The Forth console and cursor management anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-24 10:16 +0000
    Re: The Forth console and cursor management minforth@arcor.de - 2017-05-23 06:22 -0700
      Re: The Forth console and cursor management Mark Wills <markwills1970@gmail.com> - 2017-05-23 06:27 -0700
    Re: The Forth console and cursor management minforth@arcor.de - 2017-05-23 06:44 -0700
      Re: The Forth console and cursor management rickman <gnuarm@gmail.com> - 2017-05-23 11:50 -0400
    Re: The Forth console and cursor management Matthias Trute <matthias.trute@gmail.com> - 2017-05-23 09:20 -0700
      Re: The Forth console and cursor management rickman <gnuarm@gmail.com> - 2017-05-23 17:46 -0400
    Re: The Forth console and cursor management peter.m.falth@gmail.com - 2017-05-23 12:12 -0700
    Re: The Forth console and cursor management Rob Sciuk <rob@controlq.com> - 2017-05-26 12:44 -0400

#59744 — The Forth console and cursor management

<quote>
6.1.0695 ACCEPT

Because external system hardware and software may perform the ACCEPT 
function, when a line terminator is received the action of the cursor, 
and therefore the display, is implementation-defined. It is recommended 
that *the cursor remain immediately following the entered text* after a 
line terminator is received.
</quote>

Which is very elegant, but unfortunately with a standard Windows console 
an absolute swine to implement. Using file reads through stdin, Windows 
treats the enter key as a CR LF, and moves the cursor appropriately. A 
quick straw poll:

Does your favourite Forth do this (the > and < are meta chars to 
indicate input and output, the underscore is the cursor caret)

   >1 2 3 .s
   <[3] 1 2 3  ok[3]
   <_


or this?

   >1 2 3 .s [3] 1 2 3  ok[3]
   <_


And which is preferable?

-- 
Alex

[toc] | [next] | [standalone]

#59746

marți, 23 mai 2017, 14:57:32 UTC+3, Alex a scris:
> <quote>
> 6.1.0695 ACCEPT
> 
> Because external system hardware and software may perform the ACCEPT 
> function, when a line terminator is received the action of the cursor, 
> and therefore the display, is implementation-defined. It is recommended 
> that *the cursor remain immediately following the entered text* after a 
> line terminator is received.
> </quote>
> 
> Which is very elegant, but unfortunately with a standard Windows console 
> an absolute swine to implement. Using file reads through stdin, Windows 
> treats the enter key as a CR LF, and moves the cursor appropriately. A 
> quick straw poll:
> 
> Does your favourite Forth do this (the > and < are meta chars to 
> indicate input and output, the underscore is the cursor caret)
> 
>    >1 2 3 .s
>    <[3] 1 2 3  ok[3]
>    <_
> 
> 
> or this?
> 
>    >1 2 3 .s [3] 1 2 3  ok[3]
>    <_
> 
> 
> And which is preferable?
> 
> -- 
> Alex

In my experience, using file reads through stdin gives you a nice
line editor but otherwise no finer control on the line. I, for example,
don't know how to implement a working KEY? with this i/o startegy.

Lately I switched to <conio.h> and _kbhit, _getch, _putch.
You are in total control, however you should treat stdin differently
now than file i/o. For example, even a backspace you should implement
by yourself, like in many small embedded systems.

Anyway, regardless the i/o used, I would prefer (and I would implement)
the first behaviour. When I press Enter, I expect to go immediately
to the next line. When I switched to conio, I implemented it to behave
like in the stdin filed version. All I did is to print the CRLF before
interpreting the line.

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

#59747

Alex <alex@rivadpm.com> writes:
>
><quote>
>6.1.0695 ACCEPT
>
>Because external system hardware and software may perform the ACCEPT 
>function, when a line terminator is received the action of the cursor, 
>and therefore the display, is implementation-defined. It is recommended 
>that *the cursor remain immediately following the entered text* after a 
>line terminator is received.
></quote>
>
>Which is very elegant, but unfortunately with a standard Windows console 
>an absolute swine to implement. Using file reads through stdin, Windows 
>treats the enter key as a CR LF, and moves the cursor appropriately.

Under Unix you have to switch the terminal to raw mode to get decent
behaviour.  Googling for "Windows console raw mode" brought up this:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms683462%28v=vs.85%29.aspx

This tells you to disable Line input mode, Processed input mode, Echo
input mode and Processed output mode to get the console into raw mode.

> A 
>quick straw poll:
>
>Does your favourite Forth do this (the > and < are meta chars to 
>indicate input and output, the underscore is the cursor caret)
>
>   >1 2 3 .s
>   <[3] 1 2 3  ok[3]
>   <_
>
>
>or this?
>
>   >1 2 3 .s [3] 1 2 3  ok[3]
>   <_

1 2 3 .s <3> 1 2 3  ok

I don't think that the other output would be particularly revealing,
because the .S may contain a CR itself.

Better tests are:

key .

(and then press "a" without "enter").  On Gforth, SwiftForth, and VFX
this gives:

key . 97  ok

Once you have a properly working KEY (which requires raw mode), you
can build an ACCEPT on top of that.

The alternative indicated in the text above is if you cannot get a
raw-mode terminal.  Then KEY and KEY? won't work properly, and ACCEPT
will just process the complete line provided by the cooked-mode
terminal.

- 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 2017: http://www.euroforth.org/ef17/

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

#59751

On 5/23/2017 13:48, Anton Ertl wrote:
> Alex <alex@rivadpm.com> writes:
>>
>> <quote>
>> 6.1.0695 ACCEPT
>>
>> Because external system hardware and software may perform the ACCEPT
>> function, when a line terminator is received the action of the cursor,
>> and therefore the display, is implementation-defined. It is recommended
>> that *the cursor remain immediately following the entered text* after a
>> line terminator is received.
>> </quote>
>>
>> Which is very elegant, but unfortunately with a standard Windows console
>> an absolute swine to implement. Using file reads through stdin, Windows
>> treats the enter key as a CR LF, and moves the cursor appropriately.
> 
> Under Unix you have to switch the terminal to raw mode to get decent
> behaviour.  Googling for "Windows console raw mode" brought up this:
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms683462%28v=vs.85%29.aspx
> 
> This tells you to disable Line input mode, Processed input mode, Echo
> input mode and Processed output mode to get the console into raw mode.

Yup. Been there, done that, got the scars. (To correct myself, it's 
actually the echo mode to stdout that causes the cursor movement when 
"enter" is processed).

It really is a mahoosive pain handling raw mode. You loose command line 
editing & history and have to provide it yourself, and then there's the 
irritant of UTF-8 support & glyph widths, along with scrolling regions 
and other nonsense.

I've looked at pdcurses (doesn't work as advertised on windows 10, 
problems with refresh()), ConEmu (use VT100 sequences, not quite sure 
how to use it properly) and even Windows 10 native VT100 (same issues as 
ConEmu and just like raw mode with the added pain of ESC sequences).

> 
>> A
>> quick straw poll:
>>
>> Does your favourite Forth do this (the > and < are meta chars to
>> indicate input and output, the underscore is the cursor caret)
>>
>>    >1 2 3 .s
>>    <[3] 1 2 3  ok[3]
>>    <_
>>
>>
>> or this?
>>
>>    >1 2 3 .s [3] 1 2 3  ok[3]
>>    <_
> 
> 1 2 3 .s <3> 1 2 3  ok
> 
> I don't think that the other output would be particularly revealing,
> because the .S may contain a CR itself.
> 
> Better tests are:
> 
> key .
> 
> (and then press "a" without "enter").  On Gforth, SwiftForth, and VFX
> this gives:
> 
> key . 97  ok
> 
> Once you have a properly working KEY (which requires raw mode), you
> can build an ACCEPT on top of that.
> 

Good point.

-- 
Alex

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

#59757

In article <2017May23.144823@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Alex <alex@rivadpm.com> writes:
>>
>><quote>
>>6.1.0695 ACCEPT
>>
>>Because external system hardware and software may perform the ACCEPT
>>function, when a line terminator is received the action of the cursor,
>>and therefore the display, is implementation-defined. It is recommended
>>that *the cursor remain immediately following the entered text* after a
>>line terminator is received.
>></quote>
>>
>>Which is very elegant, but unfortunately with a standard Windows console
>>an absolute swine to implement. Using file reads through stdin, Windows
>>treats the enter key as a CR LF, and moves the cursor appropriately.
>
>Under Unix you have to switch the terminal to raw mode to get decent
>behaviour.  Googling for "Windows console raw mode" brought up this:
>
>https://msdn.microsoft.com/en-us/library/windows/desktop/ms683462%28v=vs.85%29.aspx
>
>This tells you to disable Line input mode, Processed input mode, Echo
>input mode and Processed output mode to get the console into raw mode.

I don't think that having line input behave like the standard with ACCEPT
describes has advantages except for CP/M compatibility.
I prefer a compatibility with Python, Guile etc.

Not playing tricks with standard i/o and accepting what the system gives
you, buys you behaviour compatible with other programs under windows,
which means that you can get commands back by arrow up and edit
them by arrow left, without any programming in the Forth.

Under linux you can run your program under rlwrap like so
    rlwrap lina
and then you get the same editing functions plus history accross
sessions just like gforth has.

>Once you have a properly working KEY (which requires raw mode), you
>can build an ACCEPT on top of that.
>
>The alternative indicated in the text above is if you cannot get a
>raw-mode terminal.  Then KEY and KEY? won't work properly, and ACCEPT
>will just process the complete line provided by the cooked-mode
>terminal.

An ACCEPT that is just a READ-FILE from standard input, allows
me to test all exceptions in ciforth using input redirection.

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

#59772

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>Under linux you can run your program under rlwrap like so
>    rlwrap lina
>and then you get the same editing functions plus history accross
>sessions just like gforth has.

Do you get TAB-completion?

>An ACCEPT that is just a READ-FILE from standard input, allows
>me to test all exceptions in ciforth using input redirection.

You mean, like

[~:63938] cat <<EOF |gforth
> 0 @
> bye
> EOF
Gforth 0.6.2, Copyright (C) 1995-2003 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
0 @ 
*the terminal*:1: Invalid memory address
0 @
  ^
Backtrace:
bye 

You don't need an ACCEPT that is a READ-FILE for that (as demonstrated
here), and I don't see the advantage over

[~:63939] gforth -e "0 @"

in file included from *the terminal*:0
*evaluated string*:-1: Invalid memory address
0 @
  ^
Backtrace:

- 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 2017: http://www.euroforth.org/ef17/

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

#59748

Am Dienstag, 23. Mai 2017 13:57:32 UTC+2 schrieb Alex:
> <quote>
> 6.1.0695 ACCEPT
> 
> Because external system hardware and software may perform the ACCEPT 
> function, when a line terminator is received the action of the cursor, 
> and therefore the display, is implementation-defined. It is recommended 
> that *the cursor remain immediately following the entered text* after a 
> line terminator is received.
> </quote>
> 
> Which is very elegant, but unfortunately with a standard Windows console 
> an absolute swine to implement. Using file reads through stdin, Windows 
> treats the enter key as a CR LF, and moves the cursor appropriately. A 
> quick straw poll:
> 
> Does your favourite Forth do this (the > and < are meta chars to 
> indicate input and output, the underscore is the cursor caret)
> 
>    >1 2 3 .s
>    <[3] 1 2 3  ok[3]
>    <_
> 
> 
> or this?
> 
>    >1 2 3 .s [3] 1 2 3  ok[3]
>    <_
> 
> 
> And which is preferable?
> 
> -- 
> Alex

You asked for it.  ;-)

MinForth V3.0 - 1048192 bytes free
> 1 2 3 .s 1 2 3  ok
1 2 3 > _

in a Win console (I like .s in the prompt..)

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

#59749

On Tuesday, 23 May 2017 14:22:18 UTC+1, minf...@arcor.de  wrote:
> Am Dienstag, 23. Mai 2017 13:57:32 UTC+2 schrieb Alex:
> > <quote>
> > 6.1.0695 ACCEPT
> > 
> > Because external system hardware and software may perform the ACCEPT 
> > function, when a line terminator is received the action of the cursor, 
> > and therefore the display, is implementation-defined. It is recommended 
> > that *the cursor remain immediately following the entered text* after a 
> > line terminator is received.
> > </quote>
> > 
> > Which is very elegant, but unfortunately with a standard Windows console 
> > an absolute swine to implement. Using file reads through stdin, Windows 
> > treats the enter key as a CR LF, and moves the cursor appropriately. A 
> > quick straw poll:
> > 
> > Does your favourite Forth do this (the > and < are meta chars to 
> > indicate input and output, the underscore is the cursor caret)
> > 
> >    >1 2 3 .s
> >    <[3] 1 2 3  ok[3]
> >    <_
> > 
> > 
> > or this?
> > 
> >    >1 2 3 .s [3] 1 2 3  ok[3]
> >    <_
> > 
> > 
> > And which is preferable?
> > 
> > -- 
> > Alex
> 
> You asked for it.  ;-)
> 
> MinForth V3.0 - 1048192 bytes free
> > 1 2 3 .s 1 2 3  ok
> 1 2 3 > _
> 
> in a Win console (I like .s in the prompt..)

My system:

1 2 3 .s 1 2 3 ok:3
_
drop ok:0
_
key . 97 ok
_

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

#59750

Am Dienstag, 23. Mai 2017 13:57:32 UTC+2 schrieb Alex:
> <quote>
> 6.1.0695 ACCEPT
> 
> Because external system hardware and software may perform the ACCEPT 
> function, when a line terminator is received the action of the cursor, 
> and therefore the display, is implementation-defined. It is recommended 
> that *the cursor remain immediately following the entered text* after a 
> line terminator is received.
> </quote>
> 
> Which is very elegant, but unfortunately with a standard Windows console 
> an absolute swine to implement. Using file reads through stdin, Windows 
> treats the enter key as a CR LF, and moves the cursor appropriately. A 
> quick straw poll:
> 
> Does your favourite Forth do this (the > and < are meta chars to 
> indicate input and output, the underscore is the cursor caret)
> 
>    >1 2 3 .s
>    <[3] 1 2 3  ok[3]
>    <_
> 
> 
> or this?
> 
>    >1 2 3 .s [3] 1 2 3  ok[3]
>    <_
> 
> 
> And which is preferable?
> 
> -- 
> Alex

The Win console API allows for setting cursor positiona and size. So it is text mode only. Win32Forth uses its own more universal console AFAIK (don't know whether it could do graphics too)

ACCEPT should not echo the return key internally. At least backspace and escape should work in any line input. For "text mode luxury" one would expect moving cursor left/right and toggle insert/overwrite. Cursor up/down for scrolling through the input history is a nice feature nice too. There is even a console API function that could be used for it.

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

#59752

minforth@arcor.de wrote:
> Am Dienstag, 23. Mai 2017 13:57:32 UTC+2 schrieb Alex:
>> <quote>
>> 6.1.0695 ACCEPT
>>
>> Because external system hardware and software may perform the ACCEPT
>> function, when a line terminator is received the action of the cursor,
>> and therefore the display, is implementation-defined. It is recommended
>> that *the cursor remain immediately following the entered text* after a
>> line terminator is received.
>> </quote>
>>
>> Which is very elegant, but unfortunately with a standard Windows console
>> an absolute swine to implement. Using file reads through stdin, Windows
>> treats the enter key as a CR LF, and moves the cursor appropriately. A
>> quick straw poll:
>>
>> Does your favourite Forth do this (the > and < are meta chars to
>> indicate input and output, the underscore is the cursor caret)
>>
>>    >1 2 3 .s
>>    <[3] 1 2 3  ok[3]
>>    <_
>>
>>
>> or this?
>>
>>    >1 2 3 .s [3] 1 2 3  ok[3]
>>    <_
>>
>>
>> And which is preferable?
>>
>> --
>> Alex
>
> The Win console API allows for setting cursor positiona and size. So it is text mode only. Win32Forth uses its own more universal console AFAIK (don't know whether it could do graphics too)

The Win32Forth console gets confused a lot.  I don't normally see issues 
with typing commands, but some of the advanced features like command 
history are problematic.  I have seen issues with I/O but I believe that 
is usually blamed on the user's program mucking outside its own variable 
space.


> ACCEPT should not echo the return key internally. At least backspace and escape should work in any line input. For "text mode luxury" one would expect moving cursor left/right and toggle insert/overwrite. Cursor up/down for scrolling through the input history is a nice feature nice too. There is even a console API function that could be used for it.
>
>


-- 

Rick C

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

#59753

> Does your favourite Forth do this (the > and < are meta chars to 
> indicate input and output, the underscore is the cursor caret)

my amforth works that way
 
>    >1 2 3 .s
>    <[3] 1 2 3  ok[3]
>    <_

> And which is preferable?

I like the look and feel of unix console sessions, therefore
a command input line ends with a line feed and the program
output starts at a new line. mixing input and output in one
line I consider confusing. Tastes differ, so this behavior
is customizable with some defers.

Matthias

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

#59761

Matthias Trute wrote:
>> Does your favourite Forth do this (the > and < are meta chars to
>> indicate input and output, the underscore is the cursor caret)
>
> my amforth works that way
>
>>    >1 2 3 .s
>>    <[3] 1 2 3  ok[3]
>>    <_
>
>> And which is preferable?
>
> I like the look and feel of unix console sessions, therefore
> a command input line ends with a line feed and the program
> output starts at a new line. mixing input and output in one
> line I consider confusing. Tastes differ, so this behavior
> is customizable with some defers.

It can be confusing at times, but if your system doesn't allow it a 
certainly level of interactivity will be lost.

-- 

Rick C

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

#59758

On Tuesday, 23 May 2017 13:57:32 UTC+2, Alex  wrote:
> <quote>
> 6.1.0695 ACCEPT
> 
> Because external system hardware and software may perform the ACCEPT 
> function, when a line terminator is received the action of the cursor, 
> and therefore the display, is implementation-defined. It is recommended 
> that *the cursor remain immediately following the entered text* after a 
> line terminator is received.
> </quote>
> 
> Which is very elegant, but unfortunately with a standard Windows console 
> an absolute swine to implement. Using file reads through stdin, Windows 
> treats the enter key as a CR LF, and moves the cursor appropriately. A 
> quick straw poll:
> 
> Does your favourite Forth do this (the > and < are meta chars to 
> indicate input and output, the underscore is the cursor caret)
> 
>    >1 2 3 .s
>    <[3] 1 2 3  ok[3]
>    <_
> 
> 
> or this?
> 
>    >1 2 3 .s [3] 1 2 3  ok[3]
>    <_
> 
> 
> And which is preferable?
> 
> -- 
> Alex

Mine does

1 2 3 .s 1 2 3  ok...

which is he way I prefer it

To get the behavior I wanted, persistent cmd history, unicode input, 
I developed my own accept based on EKEY.

EKEY was implemented using ReadConsoleInputW.
With this you get the 16 bit unicode char and all controlkey info and
function key info. It is a bit of work as ReadConsoleInputW get key presses
and releases and also mouse input.
But when it is done it works really nice

Peter

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

#59877

On Tue, 23 May 2017, Alex wrote:

> Date: Tue, 23 May 2017 12:57:30 +0100
> From: Alex <alex@rivadpm.com>
> Newsgroups: comp.lang.forth
> Subject: The Forth console and cursor management
> 
>
> <quote>
> 6.1.0695 ACCEPT
>
> Because external system hardware and software may perform the ACCEPT 
> function, when a line terminator is received the action of the cursor, and 
> therefore the display, is implementation-defined. It is recommended that *the 
> cursor remain immediately following the entered text* after a line terminator 
> is received.
> </quote>
>
> Which is very elegant, but unfortunately with a standard Windows console an 
> absolute swine to implement. Using file reads through stdin, Windows treats 
> the enter key as a CR LF, and moves the cursor appropriately. A quick straw 
> poll:
>
> Does your favourite Forth do this (the > and < are meta chars to indicate 
> input and output, the underscore is the cursor caret)
>
>  >1 2 3 .s
>  <[3] 1 2 3  ok[3]
>  <_
>
>
> or this?
>
>  >1 2 3 .s [3] 1 2 3  ok[3]
>  <_
>
>
> And which is preferable?

-- OneFileForth-Hosted alpha Version: 00.01.48F (en_US.utf8)
-- www.ControlQ.com
ok
ok 1 2 3 .s
3  :  1 2 3 ok _

The way *I* prefer it.
R.

[toc] | [prev] | [standalone]

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

csiph-web