The Forth console and cursor management

[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

[Raimond Dragomir]

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.

[Anton Ertl]

Alex <al...@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/

[minf...@arcor.de]

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..)

[Mark Wills]

My system:

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

[minf...@arcor.de]

Am Dienstag, 23. Mai 2017 13:57:32 UTC+2 schrieb 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.

[Alex]

On 5/23/2017 13:48, Anton Ertl wrote:
> Alex <al...@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

[rickman]

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

[Matthias Trute]

> 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

[Albert van der Horst]

In article <2017May2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Alex <al...@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

[peter....@gmail.com]

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

[rickman]

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

--

Rick C

[Anton Ertl]

alb...@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:

[Rob Sciuk]

On Tue, 23 May 2017, Alex wrote:

> Date: Tue, 23 May 2017 12:57:30 +0100
> From: Alex <al...@rivadpm.com>
> Newsgroups: comp.lang.forth
> Subject: The Forth console and cursor management

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