Hi Vitaliy,

On 2024-03-13 14:19:04, you wrote to me:

putty-256color just add more colors support. F keys are broken
most probably because terminfo is missing.

That is not the case...

I spend a lot of time configuring my Putty to work correctly. I'd suggest you first make it working without luit.

Then I have to set my terminals to cp850 charset. I rather keep them as utf8

You may need to play with Putty's settings. And TERM=putty works the
best for me. What I mean - it may work and it's just configuration
thing. It should be totally fine for you too because you have correct termnifo.

I can spend a lot of time on it, or keep my current working config... I see no gain, spending the time.

Bye, Wilfred.

--- FMail-lnx64 2.2.1.1
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

13 Mar 24 21:58, you wrote to me:

putty-256color just add more colors support. F keys are broken
most probably because terminfo is missing.

That is not the case...

I spend a lot of time configuring my Putty to work correctly. I'd
suggest you first make it working without luit.

Then I have to set my terminals to cp850 charset. I rather keep them
as utf8

Only temporary. F keys shall not be dependent on locale.

You may need to play with Putty's settings. And TERM=putty works
the best for me. What I mean - it may work and it's just
configuration thing. It should be totally fine for you too
because you have correct termnifo.

I can spend a lot of time on it, or keep my current working config...
I see no gain, spending the time.

Sure. If that works for you. I'm just trying to help. :)

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-13 15:31:20, you wrote to me:

I spend a lot of time configuring my Putty to work correctly. I'd
suggest you first make it working without luit.

Then I have to set my terminals to cp850 charset. I rather keep them
as utf8

Only temporary. F keys shall not be dependent on locale.

I suspect it might have to do with different escape sequences, or handling of, for the function keys in the 'linux' and 'putty' settings.

You may need to play with Putty's settings. And TERM=putty works
the best for me. What I mean - it may work and it's just
configuration thing. It should be totally fine for you too
because you have correct termnifo.

I can spend a lot of time on it, or keep my current working config...
I see no gain, spending the time.

Sure. If that works for you. I'm just trying to help. :)

And that is highly appreciated!

Bye, Wilfred.

--- FMail-lnx64 2.2.1.1
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

14 Mar 24 08:55, you wrote to me:

I spend a lot of time configuring my Putty to work correctly.
I'd suggest you first make it working without luit.

Then I have to set my terminals to cp850 charset. I rather keep
them as utf8

Only temporary. F keys shall not be dependent on locale.

I suspect it might have to do with different escape sequences, or handling of, for the function keys in the 'linux' and 'putty'
settings.

You're completely right. That's the reason. And when you change terminal type, ncurses expects different escape sequences.

My settings are:
terminal type putty

Then in Terminal->Keyboard:

The Backspace key -> Control-?
The Home and End keys -> Standard
The Function keys and keypad -> ESC[n~
Shift/Ctrl/Alt with the arrow keys -> Ctrl toggles app mode
Initial state of cursor keys -> Normal
Initial state of numeric keypad -> Normal
AltGf acts as Compose key -> off
Control-Alt is different from AltGf -> on

In Terminal->Features all is off except "Disable application keypad mode"

You may need to play with Putty's settings. And TERM=putty
works the best for me. What I mean - it may work and it's just
configuration thing. It should be totally fine for you too
because you have correct termnifo.

I can spend a lot of time on it, or keep my current working
config... I see no gain, spending the time.

Sure. If that works for you. I'm just trying to help. :)

And that is highly appreciated!

Try my settings. It could work.

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-14 07:19:32, you wrote to me:

I suspect it might have to do with different escape sequences, or
handling of, for the function keys in the 'linux' and 'putty'
settings.

You're completely right. That's the reason. And when you change terminal type, ncurses expects different escape sequences.

My settings are:
terminal type putty

Then in Terminal->Keyboard:

The Backspace key -> Control-?
The Home and End keys -> Standard
The Function keys and keypad -> ESC[n~

That was the one that was different for me.

I also had to Disable remote-controled terminal resizing, otherwise my terminal would resize to 80 chars wide after closing golded.

Shift/Ctrl/Alt with the arrow keys -> Ctrl toggles app mode
Initial state of cursor keys -> Normal
Initial state of numeric keypad -> Normal
AltGf acts as Compose key -> off
Control-Alt is different from AltGf -> on

In Terminal->Features all is off except "Disable application keypad mode"

Try my settings. It could work.

It fixed the keyboard problems. But not how golded looks. The line drawing characters are still the 'qqqqqq' kind.
It doesn't matter if I use luit or not.

What did help, was enabling in Window/Tranlation: Enable VT100 line drawing even in UTF-8 mode
So now I can use the 'putty-256color' terminal type. :-)


Bye, Wilfred.

--- FMail-lnx64 2.2.1.1
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

14 Mar 24 15:25, you wrote to me:

I suspect it might have to do with different escape sequences,
or handling of, for the function keys in the 'linux' and
'putty' settings.

You're completely right. That's the reason. And when you change
terminal type, ncurses expects different escape sequences.

My settings are:
terminal type putty

Then in Terminal->Keyboard:

The Backspace key -> Control-?
The Home and End keys -> Standard
The Function keys and keypad -> ESC[n~

That was the one that was different for me.

I also had to Disable remote-controled terminal resizing, otherwise my terminal would resize to 80 chars wide after closing golded.

Good.

Shift/Ctrl/Alt with the arrow keys -> Ctrl toggles app mode
Initial state of cursor keys -> Normal
Initial state of numeric keypad -> Normal
AltGf acts as Compose key -> off
Control-Alt is different from AltGf -> on

In Terminal->Features all is off except "Disable application
keypad mode"

Try my settings. It could work.

It fixed the keyboard problems. But not how golded looks. The line drawing characters are still the 'qqqqqq' kind. It doesn't matter if I use luit or not.

What did help, was enabling in Window/Tranlation: Enable VT100 line drawing even in UTF-8 mode So now I can use the 'putty-256color'
terminal type. :-)

The only difference that I don't run golded in UTF, that's why you had to change this parameter. Glad it works for you!

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-14 10:32:22, you wrote to me:

What did help, was enabling in Window/Tranlation: Enable VT100 line
drawing even in UTF-8 mode So now I can use the 'putty-256color'
terminal type. :-)

The only difference that I don't run golded in UTF, that's why you had to change this parameter. Glad it works for you!

My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit -encoding 'CP850'', so I don't run golded in UTF either. Or do you mean something else?

Bye, Wilfred.

--- FMail-lnx64 2.2.1.1
* Origin: FMail development HQ (2:280/464)

Hello, Wilfred!

Thursday March 14 2024 17:37, from Wilfred van Velzen -> Vitaliy Aksyonov:

My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit -encoding 'CP850'', so I don't run golded in UTF either. Or do you
mean something else?

Make sure your luit has that encoding.
$ luit -list | grep CP850

Mine doesn't
$ luit -list | grep -ic CP850
0

Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: Linux 2.6.32-042stab145.3 (2:5015/46)

Hi Nil,

On 2024-03-14 20:03:22, you wrote to me:

My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit
-encoding 'CP850'', so I don't run golded in UTF either. Or do you
mean something else?

Make sure your luit has that encoding.
$ luit -list | grep CP850

# luit -list | grep CP850
CP850: GL -> G0, GR -> G2, G0: ASCII, G2: CP 850

And otherwise it probably wouldn't have worked. ;-)

But thanks for the tip!


Bye, Wilfred.

--- FMail-lnx64 2.2.1.1
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

14 Mar 24 17:37, you wrote to me:

What did help, was enabling in Window/Tranlation: Enable VT100
line drawing even in UTF-8 mode So now I can use the
'putty-256color' terminal type. :-)

The only difference that I don't run golded in UTF, that's why
you had to change this parameter. Glad it works for you!

My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit -encoding 'CP850'', so I don't run golded in UTF either. Or do you
mean something else?

Yep. That is what I meant. Anyway I glad it works for you now.

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-14 12:29:14, you wrote to me:

What did help, was enabling in Window/Tranlation: Enable VT100
line drawing even in UTF-8 mode So now I can use the
'putty-256color' terminal type. :-)

The only difference that I don't run golded in UTF, that's why
you had to change this parameter. Glad it works for you!

My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit
-encoding 'CP850'', so I don't run golded in UTF either. Or do you
mean something else?

Yep. That is what I meant. Anyway I glad it works for you now.

I'm still seeing an issue with some messages in German areas. For instance:

https://paste.opensuse.org/pastes/0cc6a7ecd695

Some characters are displayed as '~A', where they should be able to be displayed in their right form, while others are displayed correctly.

The two High ascii characters in the marked area are:

\x81 ; latin small letter u with diaeresis
\xE1 ; greek small letter beta (here used as german ss)

The last character in the line, an 'e', isn't even displayed, probably because of the expansion of 1 of the characters to 2 characters.

These characters are the same in CP437 and CP850. So my CP850 terminal should display them correctly.
It seems to come from Golded itself, or maybe the ncurses library, because it doesn't matter if I use luit for starting Golded or not, or running it in my remote putty terminal, or my local konsole terminal. The \x81 character is always displayed as ~A ... Strange!?


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hi Vitaliy,

On 2024-03-22 09:38:52, I wrote to you:

I'm still seeing an issue with some messages in German areas. For instance:

https://paste.opensuse.org/pastes/0cc6a7ecd695

Some characters are displayed as '~A', where they should be able to be displayed in their right form, while others are displayed correctly.

The two High ascii characters in the marked area are:

\x81 ; latin small letter u with diaeresis
\xE1 ; greek small letter beta (here used as german ss)

The last character in the line, an 'e', isn't even displayed, probably because
of the expansion of 1 of the characters to 2 characters.

These characters are the same in CP437 and CP850. So my CP850 terminal should
display them correctly. It seems to come from Golded itself, or maybe the ncurses library, because it doesn't matter if I use luit for starting Golded
or not, or running it in my remote putty terminal, or my local konsole terminal. The \x81 character is always displayed as ~A ... Strange!?

Btw: My terminal seems fine with displaying the CP850 high ascii characters (despite the warning):

https://paste.opensuse.org/pastes/8bcb9d2ecfdf


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

22 Mar 24 10:45, you wrote to me:

I'm still seeing an issue with some messages in German areas.
For
instance:

https://paste.opensuse.org/pastes/0cc6a7ecd695

Some characters are displayed as '~A', where they should be able
to be displayed in their right form, while others are displayed
correctly.

The two High ascii characters in the marked area are:

\x81 ; latin small letter u with diaeresis
\xE1 ; greek small letter beta (here used as german ss)

The last character in the line, an 'e', isn't even displayed,
probably because of the expansion of 1 of the characters to 2
characters.

These characters are the same in CP437 and CP850. So my CP850
terminal should display them correctly. It seems to come from
Golded itself, or maybe the ncurses library, because it doesn't
matter if I use luit for starting Golded or not, or running it
in my remote putty terminal, or my local konsole terminal. The
\x81 character is always displayed as ~A ... Strange!?

Btw: My terminal seems fine with displaying the CP850 high ascii characters (despite the warning):

https://paste.opensuse.org/pastes/8bcb9d2ecfdf

Looks like your luit doesn't support CP850 or you don't have en_US.CP850. There are some encodings which luit list, but doesn't support actually. For example, mine lists CP866, but doesn't work with it.

Does it present in `locale -a` output?

Have you tried to run that script without luit? You don't even need to change locale for it - just encoding in terminal.

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-22 07:04:30, you wrote to me:

Btw: My terminal seems fine with displaying the CP850 high ascii
characters (despite the warning):

https://paste.opensuse.org/pastes/8bcb9d2ecfdf

Looks like your luit doesn't support CP850 or you don't have en_US.CP850. There are some encodings which luit list, but doesn't support actually. For
example, mine lists CP866, but doesn't work with it.

Does it present in `locale -a` output?

I don't know if that says much, because mostly there are just the xx_XX and xx_XX.utf8 versions of the encodings. To give you a sample:

# locale -a | grep en_
en_AG
en_AU
en_AU.utf8
en_BE
en_BE.utf8
en_BE@euro
en_BW
en_BW.utf8
en_CA
en_CA.utf8
en_DK
en_DK.utf8
en_GB
en_GB.iso885915
en_GB.utf8
en_HK
en_HK.utf8
en_IE
en_IE.utf8
en_IE@euro
en_IN
en_NG
en_NZ
en_NZ.utf8
en_PH
en_PH.utf8
en_SG
en_SG.utf8
en_US
en_US.iso885915
en_US.utf8
en_ZA
en_ZA.utf8
en_ZM
en_ZW
en_ZW.utf8

Does this mean there is just an utf8 charset and an unspecified one for almost every language-country? That doesn't seem logical!

Doesn't this show you what encodings luit supports:

# luit -list
Known locale encodings:

C: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
POSIX: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
US-ASCII: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
...
CP850: GL -> G0, GR -> G2, G0: ASCII, G2: CP 850
...

Known charsets (not all may be available):

ISO 646 (1973) (ISO 2022, 94 codes)
ASCII (ISO 2022, 94 codes)
...
CP 437 (128 codes)
CP 850 (128 codes)
CP 852 (128 codes)
...

So luit seems to know about CP850...

Have you tried to run that script without luit? You don't even need to change locale for it - just encoding in terminal.

https://paste.opensuse.org/pastes/574e349fadaf

So without luit it doesn't display anything useful. With luit, although you get the warning, it does display the right characters for CP850 !?


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

23 Mar 24 13:57, you wrote to me:

Btw: My terminal seems fine with displaying the CP850 high
ascii characters (despite the warning):

https://paste.opensuse.org/pastes/8bcb9d2ecfdf

Looks like your luit doesn't support CP850 or you don't have
en_US.CP850. There are some encodings which luit list, but
doesn't support actually. For example, mine lists CP866, but
doesn't work with it.

Does it present in `locale -a` output?

I don't know if that says much, because mostly there are just the
xx_XX and xx_XX.utf8 versions of the encodings. To give you a sample:

# locale -a | grep en_

[...skipped...]

Does this mean there is just an utf8 charset and an unspecified one
for almost every language-country? That doesn't seem logical!

It just mean that your system doesn't have necessary locale installed. And that perfectly explain why luit shows all chars, but GoldEd doesn't.

Luit converts them using internal tables to UTF, but GoldEd tries to use en_EN.CP850, which is missing. That's why it doesn't understand that letters with codes > 127 are letters.

You need to install or generate this locale and GoldEd will show those letters! What Linux distribution do you use? Do you need help with locale generation?

Doesn't this show you what encodings luit supports:

# luit -list
Known locale encodings:

C: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
POSIX: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
US-ASCII: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
...
CP850: GL -> G0, GR -> G2, G0: ASCII, G2: CP 850
...

Known charsets (not all may be available):

ISO 646 (1973) (ISO 2022, 94 codes)
ASCII (ISO 2022, 94 codes)
...
CP 437 (128 codes)
CP 850 (128 codes)
CP 852 (128 codes)
...

So luit seems to know about CP850...

Yes. And that's good!

Have you tried to run that script without luit? You don't even
need to change locale for it - just encoding in terminal.

https://paste.opensuse.org/pastes/574e349fadaf

So without luit it doesn't display anything useful. With luit,
although you get the warning, it does display the right characters for CP850 !?

Yep. I meant to run that script without luit in terminal configured for CP850. But you don't need to do that anymore as long as we found root cause already.

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-24 11:12:14, you wrote to me:

You need to install or generate this locale and GoldEd will show those letters! What Linux distribution do you use?

wilnux5:/etc # cat os-release
NAME="openSUSE Leap"
VERSION="42.1"
VERSION_ID="42.1"
PRETTY_NAME="openSUSE Leap 42.1 (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:42.1" BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"

(Yes, it's old ;-))

Do you need help with locale generation?

I think I found out how to do this on my system.

First I used my systems package manager to install: "glibc-i18ndata - Database Sources for 'locale'"

Afterwards this command ran without any output:

# localedef --no-archive -f IBM850 -i en_US en_US.CP850
#

And this directory was created with contents:

/usr/lib/locale/en_US.cp850

And 'locale -a -v' now shows:
...
locale: en_US directory: /usr/lib/locale/en_US -------------------------------------------------------------------------------
title | English locale for the USA
source | Free Software Foundation, Inc.
address | http://www.gnu.org/software/libc/
email | [email protected]
language | English
territory | USA
revision | 1.0
date | 2000-06-24
codeset | ISO-8859-1

locale: en_US.cp850 directory: /usr/lib/locale/en_US.cp850 -------------------------------------------------------------------------------
title | English locale for the USA
source | Free Software Foundation, Inc.
address | http://www.gnu.org/software/libc/
email | [email protected]
language | English
territory | USA
revision | 1.0
date | 2000-06-24
codeset | IBM850
...

But golded output is borked now, in my current utf-8 configured putty terminal:

https://paste.opensuse.org/pastes/2a5c7f2fbdc4

It doesn't matter if I use luit or not, they are displayed the same.
Also the ~A characters for messages with CHRS: CP437 in the german areas are still there.

And this is still the same:

https://paste.opensuse.org/pastes/f3961b7ea085


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

25 Mar 24 09:01, you wrote to me:

You need to install or generate this locale and GoldEd will show
those letters! What Linux distribution do you use?

wilnux5:/etc # cat os-release
NAME="openSUSE Leap"
VERSION="42.1"
VERSION_ID="42.1"
PRETTY_NAME="openSUSE Leap 42.1 (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:42.1" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://opensuse.org/"
ID_LIKE="suse"

(Yes, it's old ;-))

Got it. Not too old for FidoNet. :)

Do you need help with locale generation?

I think I found out how to do this on my system.

First I used my systems package manager to install: "glibc-i18ndata - Database Sources for 'locale'"

Afterwards this command ran without any output:

# localedef --no-archive -f IBM850 -i en_US en_US.CP850
#

And this directory was created with contents:

/usr/lib/locale/en_US.cp850

And 'locale -a -v' now shows:
...
locale: en_US directory: /usr/lib/locale/en_US ---------------------------------------------------------------------- ---------
title | English locale for the USA
source | Free Software Foundation, Inc.
address | http://www.gnu.org/software/libc/
email | [email protected]
language | English
territory | USA
revision | 1.0
date | 2000-06-24
codeset | ISO-8859-1

locale: en_US.cp850 directory: /usr/lib/locale/en_US.cp850 ---------------------------------------------------------------------- ---------
title | English locale for the USA
source | Free Software Foundation, Inc.
address | http://www.gnu.org/software/libc/
email | [email protected]
language | English
territory | USA
revision | 1.0
date | 2000-06-24
codeset | IBM850
...

This is what you need. Good.

But golded output is borked now, in my current utf-8 configured putty terminal:

https://paste.opensuse.org/pastes/2a5c7f2fbdc4

This is exactly how I saw it on my computer, when was using pseudo-graphics with wrong or missing locale.

It doesn't matter if I use luit or not, they are displayed the same.
Also the ~A characters for messages with CHRS: CP437 in the german
areas are still there.

And this is still the same:

https://paste.opensuse.org/pastes/f3961b7ea085

This looks like locale is not used. I saw such pictures when Strange.

Do you use latest GoldEd build? Do you still run it with LANG=en_US.cp850? In some message I saw en_EN.CP850.

Could you also run:
LANG=en_US.cp850 locale

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-25 07:14:50, you wrote to me:

PRETTY_NAME="openSUSE Leap 42.1 (x86_64)"

(Yes, it's old ;-))

Got it. Not too old for FidoNet. :)

Nope. ;-)

locale: en_US.cp850 directory: /usr/lib/locale/en_US.cp850

This is what you need. Good.

But golded output is borked now, in my current utf-8 configured putty
terminal:

https://paste.opensuse.org/pastes/2a5c7f2fbdc4

This is exactly how I saw it on my computer, when was using pseudo-graphics
with wrong or missing locale.

The locale is there, so is it wrong?

It doesn't matter if I use luit or not, they are displayed the same.
Also the ~A characters for messages with CHRS: CP437 in the german
areas are still there.

And this is still the same:

https://paste.opensuse.org/pastes/f3961b7ea085

This looks like locale is not used. I saw such pictures when Strange.

Do you use latest GoldEd build?

Almost. I'm using this one:

commit 4b6c754756d0fa96c0c3210d6ed0b63d49ec8e6a
Author: Vitaliy Aksyonov <[email protected]> Date: Wed Mar 6 13:38:52 2024 -0700

call setlocale() before initscr() (#86)

See section Initialization in man 3 ncurses.
https://www.man7.org/linux/man-pages/man3/ncurses.3x.html
Locale shall be initialized before ncurses initialization.

The latest one doesn't seem so change anything regarding screen output.

Do you still run it with LANG=en_US.cp850?

Yes.

In some message I saw en_EN.CP850.

The localdef command, created the directory with lowercase 'cp850' although I specified it with uppercase 'CP850'. It also shows it with lowercase 'cp' when locale -a is executed. So I switched to specifying it as lowercase in my golded start script. But case probably doesn't matter.

Could you also run:
LANG=en_US.cp850 locale

Here are some tries:

wilnux5:/home/fido/log # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

wilnux5:/home/fido/log # LANG=en_US.cp850 locale
LANG=en_US.cp850
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="en_US.cp850"
LC_TIME="en_US.cp850"
LC_COLLATE="en_US.cp850"
LC_MONETARY="en_US.cp850"
LC_MESSAGES="en_US.cp850"
LC_PAPER="en_US.cp850"
LC_NAME="en_US.cp850"
LC_ADDRESS="en_US.cp850"
LC_TELEPHONE="en_US.cp850"
LC_MEASUREMENT="en_US.cp850"
LC_IDENTIFICATION="en_US.cp850"
LC_ALL=

wilnux5:/home/fido/log # LANG=en_US.CP850 locale
LANG=en_US.CP850
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="en_US.CP850"
LC_TIME="en_US.CP850"
LC_COLLATE="en_US.CP850"
LC_MONETARY="en_US.CP850"
LC_MESSAGES="en_US.CP850"
LC_PAPER="en_US.CP850"
LC_NAME="en_US.CP850"
LC_ADDRESS="en_US.CP850"
LC_TELEPHONE="en_US.CP850"
LC_MEASUREMENT="en_US.CP850"
LC_IDENTIFICATION="en_US.CP850"
LC_ALL=

wilnux5:/home/fido/log # sudo -u fido LANG=en_US.cp850 locale
LANG=en_US.cp850
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="en_US.cp850"
LC_TIME="en_US.cp850"
LC_COLLATE="en_US.cp850"
LC_MONETARY="en_US.cp850"
LC_MESSAGES="en_US.cp850"
LC_PAPER="en_US.cp850"
LC_NAME="en_US.cp850"
LC_ADDRESS="en_US.cp850"
LC_TELEPHONE="en_US.cp850"
LC_MEASUREMENT="en_US.cp850"
LC_IDENTIFICATION="en_US.cp850"
LC_ALL=


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

25 Mar 24 15:13, you wrote to me:

locale: en_US.cp850 directory: /usr/lib/locale/en_US.cp850

This is what you need. Good.

But golded output is borked now, in my current utf-8 configured
putty
terminal:
https://paste.opensuse.org/pastes/2a5c7f2fbdc4

This is exactly how I saw it on my computer, when was using
pseudo-graphics with wrong or missing locale.

The locale is there, so is it wrong?

I have no idea. It looks correct. But output looks like ncurses uses incorrect locale.

It doesn't matter if I use luit or not, they are displayed the
same. Also the ~A characters for messages with CHRS: CP437 in
the german areas are still there.

Remind me. Do you have XLAT conversion table from cp437 to cp850?

And this is still the same:

https://paste.opensuse.org/pastes/f3961b7ea085

This looks like locale is not used. I saw such pictures when
Strange.

Do you use latest GoldEd build?

Almost. I'm using this one:

commit 4b6c754756d0fa96c0c3210d6ed0b63d49ec8e6a
Author: Vitaliy Aksyonov <[email protected]>
Date: Wed Mar 6 13:38:52 2024 -0700

call setlocale() before initscr() (#86)

See section Initialization in man 3 ncurses.
https://www.man7.org/linux/man-pages/man3/ncurses.3x.html
Locale shall be initialized before ncurses initialization.

The latest one doesn't seem so change anything regarding screen
output.

Looks like incorrect locale to me again.

Do you still run it with LANG=en_US.cp850?

Yes.

In some message I saw en_EN.CP850.

The localdef command, created the directory with lowercase 'cp850' although I specified it with uppercase 'CP850'. It also shows it with lowercase 'cp' when locale -a is executed. So I switched to specifying
it as lowercase in my golded start script. But case probably doesn't matter.

No, I mean that i saw you using en_*EN*.cp850, not en_*US*.cp850. That is important.

Could you also run:
LANG=en_US.cp850 locale

Here are some tries:

wilnux5:/home/fido/log # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8

^^^^^
This is not correct

LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"

^^^^^^^
These guys too.

LC_ALL=

[...skipped...]

Make sure that all LC_-s are en_US.cp850. Especially LC_CTYPE.

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-25 11:09:34, you wrote to me:

This is exactly how I saw it on my computer, when was using
pseudo-graphics with wrong or missing locale.

The locale is there, so is it wrong?

I have no idea. It looks correct. But output looks like ncurses uses incorrect
locale.

It seems so.

It doesn't matter if I use luit or not, they are displayed the
same. Also the ~A characters for messages with CHRS: CP437 in
the german areas are still there.

Remind me. Do you have XLAT conversion table from cp437 to cp850?

Yes.

In some message I saw en_EN.CP850.

The localdef command, created the directory with lowercase 'cp850'
although I specified it with uppercase 'CP850'. It also shows it
with
lowercase 'cp' when locale -a is executed. So I switched to specifying
it as lowercase in my golded start script. But case probably doesn't
matter.

No, I mean that i saw you using en_*EN*.cp850, not en_*US*.cp850. That is important.

O, sorry, I didn't notice the "_EN"...

That was what I first tried, but that made no sense, since I don't have any en_EN* locales at all (there are the en_GB* locales though).

wilnux5:/home/fido/log # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8

^^^^^
This is not correct

Ok.

Make sure that all LC_-s are en_US.cp850. Especially LC_CTYPE.

Ok that did the trick! Just setting LC_CTYPE=en_US.cp850 is enough. So now I have the following line for starting golded:

sudo -u fido LC_CTYPE=en_US.cp850 luit -encoding 'CP850' /usr/local/bin/golded -f

The linedrawing characters, and the german characters (with @CHRS: CP437) are ok too!

So this:

# sudo -u fido LC_CTYPE=en_US.cp850 locale
LANG=POSIX
LC_CTYPE=en_US.cp850
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Seems enough to get the right output from golded!?


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

25 Mar 24 21:18, you wrote to me:

Make sure that all LC_-s are en_US.cp850. Especially LC_CTYPE.

Ok that did the trick! Just setting LC_CTYPE=en_US.cp850 is enough. So now I have the following line for starting golded:

Great! Glad to help.

sudo -u fido LC_CTYPE=en_US.cp850 luit -encoding 'CP850' /usr/local/bin/golded -f

The linedrawing characters, and the german characters (with @CHRS:
CP437) are ok too!

So this:

# sudo -u fido LC_CTYPE=en_US.cp850 locale
LANG=POSIX
LC_CTYPE=en_US.cp850
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Seems enough to get the right output from golded!?

Other LCs are pretty much not used in GoldEd, shall be fine for your case.

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-25 19:03:38, you wrote to me:

Ok that did the trick! Just setting LC_CTYPE=en_US.cp850 is enough.
So now I have the following line for starting golded:

Great! Glad to help.

Yes, thank you very much!

# sudo -u fido LC_CTYPE=en_US.cp850 locale
LANG=POSIX
LC_CTYPE=en_US.cp850
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Seems enough to get the right output from golded!?

Other LCs are pretty much not used in GoldEd, shall be fine for your case.

Pretty much? Or not at all? ;-)


On to the next issues... ;-)

I notice in my putty terminal that alignment of the columns in the area listing is off when there are unread messages in the areas:

https://paste.opensuse.org/pastes/1b0a6ac1a41e

This might not be new, and already happening before I started changing/fixing my code page issues. I'll check later if this also happens in my local konsole terminal.

Also the header with the number of messages on the message reader screen is sometimes missing a space between the first number and 'of', when I go directly to a message from the area messages listing.

https://paste.opensuse.org/pastes/80901e9650d8

Could this be related to the above issue?


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hi Vitaliy,

On 2024-03-26 11:20:42, I wrote to you:

On to the next issues... ;-)

I notice in my putty terminal that alignment of the columns in the area listing is off when there are unread messages in the areas:

https://paste.opensuse.org/pastes/1b0a6ac1a41e

This might not be new, and already happening before I started changing/fixing
my code page issues. I'll check later if this also happens in my local konsole
terminal.

In my local konsole it's fine. There is a '>' character after the 0 on lines for areas where there is new mail.

Also the header with the number of messages on the message reader
screen is sometimes missing a space between the first number and
'of', when I go directly to a message from the area messages listing.

https://paste.opensuse.org/pastes/80901e9650d8

Could this be related to the above issue?

I don't see this happening in my local konsole terminal either.


This probably means I have to play with my putty settings (again)... :-/ ;-)


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

26 Mar 24 18:02, you wrote to me:

On to the next issues... ;-)

I notice in my putty terminal that alignment of the columns in
the area listing is off when there are unread messages in the
areas:

https://paste.opensuse.org/pastes/1b0a6ac1a41e

This might not be new, and already happening before I started
changing/fixing my code page issues. I'll check later if this
also happens in my local konsole terminal.

In my local konsole it's fine. There is a '>' character after the 0 on lines for areas where there is new mail.

Interesting. I assume you use luit with same configuration/locale in local console and putty?

Also the header with the number of messages on the message
reader screen is sometimes missing a space between the first
number and 'of', when I go directly to a message from the area
messages listing.

https://paste.opensuse.org/pastes/80901e9650d8

Could this be related to the above issue?

I don't see this happening in my local konsole terminal either.

This probably means I have to play with my putty settings (again)...
:-/ ;-)

You full of surprises! :) Just kidding.

It may be lost in so many layers you use... I'd suggest to check if putty and local console use same/different TERM.

echo $TERM

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-26 16:17:06, you wrote to me:

In my local konsole it's fine. There is a '>' character after the 0
on lines for areas where there is new mail.

Interesting. I assume you use luit with same configuration/locale in local console and putty?

Yes.

Also the header with the number of messages on the message
reader screen is sometimes missing a space between the first
number and 'of', when I go directly to a message from the area
messages listing.

https://paste.opensuse.org/pastes/80901e9650d8

Could this be related to the above issue?

I don't see this happening in my local konsole terminal either.

This probably means I have to play with my putty settings (again)...
:-/ ;-)

You full of surprises! :) Just kidding.

Well it helped! I switched to the $TERM=putty-256color settings we discussed before, and now all is well!

It may be lost in so many layers you use... I'd suggest to check if
putty and local console use same/different TERM.

echo $TERM

Is is 'xterm' in my local konsole, and was 'linux' but now 'putty-256color' in my putty terminal.


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

27 Mar 24 09:58, you wrote to me:

Also the header with the number of messages on the message
reader screen is sometimes missing a space between the first
number and 'of', when I go directly to a message from the area
messages listing.

https://paste.opensuse.org/pastes/80901e9650d8

Could this be related to the above issue?

I don't see this happening in my local konsole terminal either.

This probably means I have to play with my putty settings
(again)...
:-/ ;-)

You full of surprises! :) Just kidding.

Well it helped! I switched to the $TERM=putty-256color settings we discussed before, and now all is well!

Great. Looks like some question need to be saved in FAQ. I only never saw English version of it.

It may be lost in so many layers you use... I'd suggest to check
if putty and local console use same/different TERM.

echo $TERM

Is is 'xterm' in my local konsole, and was 'linux' but now 'putty-256color' in my putty terminal.

256color make console very different in other programs too.

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-27 06:57:44, you wrote to me:

Well it helped! I switched to the $TERM=putty-256color settings we
discussed before, and now all is well!

Great. Looks like some question need to be saved in FAQ. I only never saw English version of it.

I don't think it exists.

echo $TERM

Is is 'xterm' in my local konsole, and was 'linux' but now
'putty-256color' in my putty terminal.

256color make console very different in other programs too.

I haven't tested the regular TERM=putty, but compared to TERM=linux, Midnight Commander looks the same. But my own ncurses program (configuration program for FMail tosser), looks ok now too!

https://paste.opensuse.org/pastes/c77fdc8fd4af

In the background how it looks with 'putty-256color' and how it is supposed to look. In the forground how it looks if TERM=linux.

Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)

Hello Wilfred.

27 Mar 24 14:28, you wrote to me:

Well it helped! I switched to the $TERM=putty-256color settings
we discussed before, and now all is well!

Great. Looks like some question need to be saved in FAQ. I only
never saw English version of it.

I don't think it exists.

I think so. :)

echo $TERM

Is is 'xterm' in my local konsole, and was 'linux' but now
'putty-256color' in my putty terminal.

256color make console very different in other programs too.

I haven't tested the regular TERM=putty, but compared to TERM=linux, Midnight Commander looks the same. But my own ncurses program (configuration program for FMail tosser), looks ok now too!

ncurses uses terminfo and `linux` not the best for Putty. `xterm` may work, but `putty` or `putty-256color` is the best for sure.

https://paste.opensuse.org/pastes/c77fdc8fd4af

In the background how it looks with 'putty-256color' and how it is supposed to look. In the forground how it looks if TERM=linux.

putty-256color just add colors. Not every program will look different. For example `ls` will.

Vitaliy

... 640K ought to be enough for anybody
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

Hi Vitaliy,

On 2024-03-27 08:07:34, you wrote to me:

256color make console very different in other programs too.

I haven't tested the regular TERM=putty, but compared to TERM=linux,
Midnight Commander looks the same. But my own ncurses program
(configuration program for FMail tosser), looks ok now too!

https://paste.opensuse.org/pastes/c77fdc8fd4af

In the background how it looks with 'putty-256color' and how it is
supposed to look. In the forground how it looks if TERM=linux.

ncurses uses terminfo and `linux` not the best for Putty. `xterm` may work,
but `putty` or `putty-256color` is the best for sure.

My program works correctly in 'xterm' too.


Bye, Wilfred.

--- FMail-lnx64 2.3.0.1-B20240319
* Origin: FMail development HQ (2:280/464)