From Newsgroup: comp.lang.forth

Formerly I had this clunky handling of colors.
I revisited this because I want to have tetris on a terminal
with colored blocks, not characters.

--------------------------------
HEX 1B CONSTANT ESC DECIMAL

CREATE ESCAPE-COLOR
ESC C, &[ C, HERE _ C, _ C, &; C, HERE _ C, _ C, &; C, &1 C, &m C,
CONSTANT ESCAPE-FORE CONSTANT ESCAPE-BACK

: SEND-COLOR-ESCAPE ESCAPE-COLOR 10 TYPE ;

: fore ESCAPE-FORE SWAP CMOVE ;
: back ESCAPE-BACK SWAP CMOVE ;

: FORE-COLOR CREATE $, DROP DOES> $@ fore SEND-COLOR-ESCAPE ;

: BACK-COLOR CREATE $, DROP DOES> $@ back SEND-COLOR-ESCAPE ;

: COLOR-ESCAPE CREATE $, DROP DOES> ESC EMIT &[ EMIT $@ TYPE ;

\ Put the screen in a mode such as to print the chars in the color.
"37" FORE-COLOR white
"37;1m" COLOR-ESCAPE white2
"36" FORE-COLOR aqua
"32" FORE-COLOR green
"33" FORE-COLOR yellow
"31" FORE-COLOR red
"35" FORE-COLOR pink
"34" FORE-COLOR fblue
"30" FORE-COLOR f30

\ Put the screen in a mode such as the background color.
"40" BACK-COLOR black
"41" BACK-COLOR b41
"42" BACK-COLOR b42
"43" BACK-COLOR b43
"44" BACK-COLOR blue
"45" BACK-COLOR b45
"46" BACK-COLOR b46
"47" BACK-COLOR b47
"48" BACK-COLOR b48
"49" BACK-COLOR bwhite

\ Print text in white, not bold.
\ This is sufficient to overrule coloring.
"0m" COLOR-ESCAPE default-white
\ Print text with foreground and background colors swapped.
"7m" COLOR-ESCAPE reverse

[ This was in behalf of syntax coloring.
CREATE RENDER-TABLE \ Colors in relation to stack effect. 1]
\ Unknown 0 1 2
'pink , 'white , 'aqua , 'green ,
\ 3 >3 ....
'yellow , 'red , 'red , 'red ,
]

--------------------------------------------
Now if you have FORMAT this becomes a lot less clunky.
It is similar to what MPEforth has.
FORMAT copies until a % , then parses a word until a blank.
This is supposed to sit in a special wordlists and generates
output.
An example of use is:
%d consumes a integer and copies the formatted output.
%e adds an escape to the output, etc.
In the end FORMAT returns a (static) string.
Like so:

\ -------------------------------------------------------
WANT REGRESS PAGE FORMAT

: ESC-COLOR CREATE "%e [%d ;1m" FORMAT $, DROP DOES> $@ TYPE ;

\ Put the screen in a mode such as to print the chars in the color.
: ESC-COLORS DO I ESC-COLOR LOOP ;
38 30 ESC-COLORS black red green yellow blue pink aqua grey

48 40 ESC-COLORS bblack bred bgreen byellow bblue bpink baqua bgrey

\ This is sufficient to reset coloring, back and fore ground.
: default-bw "%e [00m" FORMAT TYPE ;
\ -------------------------------------------------------


1] Stack effect coloring never catches on.
2] $, (addr len -- addr) where the first cell stores the count.
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 30-04-2026 04:11, dxf wrote:

On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

You might have a look at 4tH's TERMANSI.4TH, which does a similar thing.
It's got some awkward base-saving code there, but I might replace that
with BASE&EXEC calls. That's not much work.

The [FORCE] directives are a typical 4tH directive to counter some side effects.

https://sourceforge.net/p/forth-4th/code/HEAD/tree/trunk/4th.src/lib/termansi.4th

Hans Bezemer
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <69f2ba42$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

You don't realize that FORMAT makes escapes in strings
superfluous. It is a loadable alternative that is not
intrusive unlike escapes in strings, that are forever contraversial.
Follow the c-crowd for escapes? Or the FORTRAN crowd?
Add it to the Forth standard? If you do that you irreversibly
complicate the Forth kernel and add another bone of contention
in the mix.

Once you embrace `` $@ $! $+! $C+ $/ $\ '' string packet,
FORMAT is just one screen.
If you don't want it, you don't load it.

--------------------------------------------------------
( FORMAT FORMAT&EVAL .FORMAT ) \ AH&CH C2feb15
DATA CRS$ 4096 ALLOT \ ":2" WANTED
NAMESPACE FORMAT-WID FORMAT-WID DEFINITIONS
: d S>D 0 (D.R) CRS$ $+! ; \ Add INT as a string.
: s CRS$ $+! ; : c CRS$ $C+ ; \ Add a STRING / CHAR as such.
: n ^J c ; : r ^M c ; : e 27 c ; \ Add single char's
PREVIOUS DEFINITIONS
\ Format the first part of STRING, up till %, leave REST.
: _plain &% $/ CRS$ $+! ;
\ Format X with first word of STRING, up till BL, leave REST.
: _format BL $/ 2SWAP >R >R 'FORMAT-WID >WID (FIND) NIP NIP
DUP 0= 51 ?ERROR EXECUTE R> R> ;
\ Format X1 .. Xn using the format STRING.
: FORMAT 0 CRS$ ! BEGIN DUP WHILE _plain DUP IF _format THEN
REPEAT 2DROP CRS$ $@ ;
: FORMAT&EVAL FORMAT EVALUATE ; : .FORMAT FORMAT TYPE ; --------------------------------------------------------

Once FORMAT is present, simple oo is two screens (actually
one screen, the other is another universal tool.)
Escaped strings doesn't help with defining oo.
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <69f2ba42$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

Now consider this:
: AT-XY 1+ SWAP 1+ SWAP "%e [%d ;%d H" .FORMAT ; \ ISO

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 30/04/2026 7:11 pm, albert@spenarnc.xs4all.nl wrote:

In article <69f2ba42$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

Now consider this:
: AT-XY 1+ SWAP 1+ SWAP "%e [%d ;%d H" .FORMAT ; \ ISO

What if the digits field had to be exactly 2 or 3 digits to suit
a specific terminal? You would have to code for it. Worst case
is something like Turbo Pascal which handled almost any terminal.
In DX-Forth for CP/M, here's how that looks:

https://pastebin.com/EvZvaaCw

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <69f36016$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 30/04/2026 7:11 pm, albert@spenarnc.xs4all.nl wrote:

In article <69f2ba42$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

Now consider this:
: AT-XY 1+ SWAP 1+ SWAP "%e [%d ;%d H" .FORMAT ; \ ISO

What if the digits field had to be exactly 2 or 3 digits to suit
a specific terminal? You would have to code for it. Worst case
is something like Turbo Pascal which handled almost any terminal.
In DX-Forth for CP/M, here's how that looks:

https://pastebin.com/EvZvaaCw

You have to code, but it is not hard. <# # #> are your friends.

You have to be careful, because there is only one hold area.
: prepare 1+ 0 <# # # # #> ;
: AT-XY SWAP prepare "%e [%s " .FORMAT prepare ";%s H" .FORMAT ; \ ISO
I wonder how you handle that with escapes in a regular string.

Or if you have an ALLOCATE available, you can make strings permanent.
: prepare 1+ 0 <# # # # #> >permanent ;
and it is even easier.

: >permanent DUP CELL+ ALLOCATE THROW >R R@ $! R> @$ ;


Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Am 30.04.2026 um 11:11 schrieb albert@spenarnc.xs4all.nl:

In article <69f2ba42$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

Now consider this:
: AT-XY 1+ SWAP 1+ SWAP "%e [%d ;%d H" .FORMAT ; \ ISO

While

AT-XY \ ( col row -- ) 10.6.1.0742 set text cursor coordinates

is standard,

XY \ ( -- col row ) get text cursor coordinates

is much more interesting to implement. ;-)
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 30-04-2026 11:06, albert@spenarnc.xs4all.nl wrote:

In article <69f2ba42$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

You don't realize that FORMAT makes escapes in strings
superfluous. It is a loadable alternative that is not
intrusive unlike escapes in strings, that are forever contraversial.
Follow the c-crowd for escapes? Or the FORTRAN crowd?
Add it to the Forth standard? If you do that you irreversibly
complicate the Forth kernel and add another bone of contention
in the mix.

Once you embrace `` $@ $! $+! $C+ $/ $\ '' string packet,
FORMAT is just one screen.
If you don't want it, you don't load it.

If that is the FORMAT from https://groups.google.com/g/comp.lang.forth/c/3tKygtfS_kI/m/PLVMYGXJBgAJ
- yeah, I remember that one! It's a cute sprintf() like library. Yeah, I
dig that one!

Hans Bezemer

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 1/05/2026 2:11 am, albert@spenarnc.xs4all.nl wrote:

In article <69f36016$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 30/04/2026 7:11 pm, albert@spenarnc.xs4all.nl wrote:

In article <69f2ba42$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote: >>>> On 29/04/2026 11:41 pm, albert@spenarnc.xs4all.nl wrote:

Formerly I had this clunky handling of colors.
...
Now if you have FORMAT this becomes a lot less clunky.

I agree the original was clunky. But whether FORMAT was necessary,
I'm less certain. Naturally, I'm too lazy to show an alternative.
But I can for your last example, as I'm sure can others ...

: default-bw "%e [00m" FORMAT TYPE ;

: default-bw ." \1b[00m" ;

Now consider this:
: AT-XY 1+ SWAP 1+ SWAP "%e [%d ;%d H" .FORMAT ; \ ISO

What if the digits field had to be exactly 2 or 3 digits to suit
a specific terminal? You would have to code for it. Worst case
is something like Turbo Pascal which handled almost any terminal.
In DX-Forth for CP/M, here's how that looks:

https://pastebin.com/EvZvaaCw

You have to code, but it is not hard. <# # #> are your friends.

You have to be careful, because there is only one hold area.
: prepare 1+ 0 <# # # # #> ;
: AT-XY SWAP prepare "%e [%s " .FORMAT prepare ";%s H" .FORMAT ; \ ISO
I wonder how you handle that with escapes in a regular string.

Or if you have an ALLOCATE available, you can make strings permanent.
: prepare 1+ 0 <# # # # #> >permanent ;
and it is even easier.

: >permanent DUP CELL+ ALLOCATE THROW >R R@ $! R> @$ ;

From a Gforth include:

: pn ( n -- ) 0 <# # # #> type ;
: ;pn [char] ; emit pn ;
: ESC[ 27 emit [char] [ emit ;
: at-xy 1+ 1 under+ ESC[ pn ;pn [char] H emit ;


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> writes:

From a Gforth include:

: pn ( n -- ) 0 <# # # #> type ;
: ;pn [char] ; emit pn ;
: ESC[ 27 emit [char] [ emit ;
: at-xy 1+ 1 under+ ESC[ pn ;pn [char] H emit ;

Here's another one (the one active when I invoke Gforth):

: #n ( n -- ) [: 0 #s 2drop ;] #10 base-execute ;
: #n; ( n -- ) #n ';' hold ;
: #esc[ ( -- )
s\" \e[" holds ;

: vt100-at-xy ( u1 u2 -- )
1+ swap 1+ <<# 'H' hold #n; #n #esc[ #0. #> type #>> ;

Benefits:

1) Works also as intended when invoked while BASE is not decimal (BASE-EXECUTE).

2) Does not disturb any ongoing hold buffer usage (<<# ... #>>).

3) Stack effect comments.

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 1/05/2026 4:03 pm, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

From a Gforth include:

: pn ( n -- ) 0 <# # # #> type ;
: ;pn [char] ; emit pn ;
: ESC[ 27 emit [char] [ emit ;
: at-xy 1+ 1 under+ ESC[ pn ;pn [char] H emit ;

Here's another one (the one active when I invoke Gforth):

: #n ( n -- ) [: 0 #s 2drop ;] #10 base-execute ;
: #n; ( n -- ) #n ';' hold ;
: #esc[ ( -- )
s\" \e[" holds ;

: vt100-at-xy ( u1 u2 -- )
1+ swap 1+ <<# 'H' hold #n; #n #esc[ #0. #> type #>> ;

Benefits:

1) Works also as intended when invoked while BASE is not decimal (BASE-EXECUTE).

2) Does not disturb any ongoing hold buffer usage (<<# ... #>>).

3) Stack effect comments.

IIRC the standard makes no mention of what needs preserving. Some implementations preserve BASE; while others don't. Here you preserve
the HOLD buffer as well.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/30/26 1:47 PM, minforth wrote:

Am 30.04.2026 um 11:11 schrieb albert@spenarnc.xs4all.nl:

...

While

AT-XY  \ ( col row -- ) 10.6.1.0742 set text cursor coordinates

is standard,

XY  \ ( -- col row ) get text cursor coordinates

is much more interesting to implement.  ;-)

: at-xy? ( -- x y | return the current cursor coordinates)
ansi_escape ." 6n"
key drop key drop \ <esc> [
[char] ; read-cdnumber [char] R read-cdnumber
1- swap 1- ;

The above definition is from kForth's ansi.4th:

https://github.com/mynenik/kForth-64/blob/master/forth-src/ansi.4th


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> writes:

IIRC the standard makes no mention of what needs preserving.

It actually states explicitly what is not guaranteed to be preserved.
In particular, <https://forth-standard.org/standard/usage#subsubsection.3.3.3.6>
says:

|The previous contents of the regions identified by [...] #> may be
|invalid after each use of these words. Further, the regions returned
|by [...] #> may overlap in memory. Consequently, use of one of these
|words can corrupt a region returned earlier by a different word. The
|other words that construct pictured numeric output strings (<#, #, #S,
|HOLD, HOLDS, XHOLD) may also modify the contents of these
|regions. Words that display numbers may be implemented using pictured
|numeric output words. Consequently, . (dot), .R, .S, ?, D., D.R, U.,
|U.R could also corrupt the regions.

Note that AT-XY is not included in this list (and chapter 10 does not
add it to this list). So

123. <# #s #> 3 4 at-xy type

should display "123" at position 3,4. Testing this with a few Forth
systems, gforth, iforth, and SwiftForth pass this test, while lxf and
VFX don't.

Some
implementations preserve BASE; while others don't.

As far as standard words are concerned, only DECIMAL and HEX are
allowed to change BASE (the specification of DECIMAL could be better,
however), and of courseyou can change BASE explicitly, e.g., with

BASE !

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/05/2026 12:11 am, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

IIRC the standard makes no mention of what needs preserving.

It actually states explicitly what is not guaranteed to be preserved.
In particular, <https://forth-standard.org/standard/usage#subsubsection.3.3.3.6>
says:

|The previous contents of the regions identified by [...] #> may be
|invalid after each use of these words. Further, the regions returned
|by [...] #> may overlap in memory. Consequently, use of one of these
|words can corrupt a region returned earlier by a different word. The
|other words that construct pictured numeric output strings (<#, #, #S, |HOLD, HOLDS, XHOLD) may also modify the contents of these
|regions. Words that display numbers may be implemented using pictured |numeric output words. Consequently, . (dot), .R, .S, ?, D., D.R, U.,
|U.R could also corrupt the regions.

Note that AT-XY is not included in this list (and chapter 10 does not
add it to this list). So

123. <# #s #> 3 4 at-xy type

should display "123" at position 3,4. Testing this with a few Forth
systems, gforth, iforth, and SwiftForth pass this test, while lxf and
VFX don't.

AFAICS there's nothing in the standard that says it "should" display
123 in that case. What happens in the absence of specification becomes
a matter of interpretation. We know the standard made effort to specify
corner cases e.g. u=0 in CMOVE. So if it were up to me I would say the standard simply didn't consider the case you specify. One certainly
needs to ask what is the likelihood of the case you specify arising.

Some
implementations preserve BASE; while others don't.
As far as standard words are concerned, only DECIMAL and HEX are

allowed to change BASE (the specification of DECIMAL could be better, however), and of courseyou can change BASE explicitly, e.g., with

BASE !

Unlike the HOLD buffer, I would say a case can be made for preserving
BASE across AT-XY calls. Since ANSI AT-XY sends coords in ASCII decimal
rather than binary, it would be a burden on apps to ensure BASE was
decimal. In such case I would seriously have to consider Albert's
DEC: - irrespective of whether my AT-XY was personally affected or not.
From a brief survey I would say most ANSI AT-XY implementations do in
fact preserve BASE. And perhaps the standard should specify that.

--- Synchronet 3.22a-Linux NewsLink 1.2