On Fri, 23 Feb 2024 04:11:24 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

Default is to use whole window. Then it's weird, that line is broken.

 NB>> 8e9f3518ac9b3b32676e7b7563e92cc44e7b5ba7 is the commit that changes
 NB>> things for the better in my case.

 NB>> It stayed that way until you reverted the commit in the latest
 NB>> version.

That's something. Thanks for doing that.

Anything I can do to help out.

Have you tried to run it in local terminal emulator? Do you have any GUI on
that computer?

It's a headless Linux VM on my ESXi server. No GUI. But I was able to test two methods besides PuTTY.

1) I logged in to my VMWare ESXi web interface, and opened the VM in a window there.

2) My main PC with Windows 11, command prompt > ssh via command line.

Both options show basically the same results, except I'd guess the VMware window is probably pretty basic and the font may not support all of the characters.

VMWare:

https://pharcyde.org/golded-vmware-stats.png

Windows command prompt:

https://pharcyde.org/golded-windowscmd-stats.png

Putty may be pain in the ass to configure correctly.

Seems pretty similar to the other methods I was able to try.

Would be cool if you may share your config and message base with message containing pseudo-graphics for me to play with. If I reproduce it internally - then I may find the cause very quickly! By config I mean not only golded.cfg, but all included files, including charset tables.

Sure. I will netmail you a link to the zip file. You will most likely have the directory structure in the config to make things work, but otherwise all pertinent information should be there.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Fri, 23 Feb 2024 22:30:26 -0600, Nicholas Boel -> Vitaliy Aksyonov wrote:

Sure. I will netmail you a link to the zip file. You will most likely have the directory structure in the config to make things work, but otherwise all pertinent information should be there.

"You will most likely have *to change* the directory structure."

It was not a Golded bug, it was user error. ;)

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Nicholas.

23 Feb 24 16:39, you wrote to you:

Sure. I will netmail you a link to the zip file. You will most
likely have the directory structure in the config to make things
work, but otherwise all pertinent information should be there.

"You will most likely have *to change* the directory structure."

It was not a Golded bug, it was user error. ;)

I'll definitely play with your config to find that issue. Thanks!

Vitaliy

... B ?ape?ax ?e? ??oxux ?a??opo?!
--- GoldED+/LNX 1.1.5-b20240223
* Origin: Aurora, Colorado (1:104/117)

Hello Nicholas!

16 Feb 24 17:15, you wrote to me:

Are you referring to having these issues with a version from 2018? If
so, I would suggest you upgrade to the latest version and see if you
have any of the same issues you have now.

Just did and same result (= same issues).

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

On Sun, 3 Mar 2024 16:41:58 +0100, Karel Kral -> Nicholas Boel wrote:

Are you referring to having these issues with a version from 2018? If
so, I would suggest you upgrade to the latest version and see if you
have any of the same issues you have now.

Just did and same result (= same issues).

I would suggest trying some translation tables. I had to look back at
your original messages about this since it was a few weeks ago already.
I did see there that you said you are not using any (maybe one)
translation tables?

If that is the case, and you have the sources, try including 'golded-plus/cfgs/config/charsets.cfg' in your golded.conf and see if
that helps or not.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Nicholas!

03 Mar 24 08:52, you wrote to me:

If that is the case, and you have the sources, try including 'golded-plus/cfgs/config/charsets.cfg' in your golded.conf and see if
that helps or not.

Already have that since ever.

For that group I have:

GROUP B
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP437 LATIN-2 asc_il2.chs
XLATCHARSET LATIN-2 CP437 il2_asc.chs
XLATIMPORT CP437
XLATIMPORT CP437
XLATLOCALSET LATIN-2
MSGLISTWIDESUBJ YES
ENDGROUP

Using UTF-8 in putty, having LANG=cs_CZ.utf8 in bash, startin golded:
luit -encoding 'ISO-8859-2' ./gedlnx -f

(because GROUP A we have ISO-8859-2 as agreed coding)

As I wrote, I have issue in GROUP B, GOLDED here...

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

On Fri, 8 Mar 2024 00:40:06 +0100, Karel Kral -> Nicholas Boel wrote:

For that group I have:

GROUP B
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP437 LATIN-2 asc_il2.chs
XLATCHARSET LATIN-2 CP437 il2_asc.chs
XLATIMPORT CP437
XLATIMPORT CP437
XLATLOCALSET LATIN-2
MSGLISTWIDESUBJ YES
ENDGROUP

Are you using the wrong translation table? I think you should be using
cp437 -> il2, rather than ascii -> il2.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Karel.

07 Mar 24 18:40, you wrote to Nicholas Boel:

If that is the case, and you have the sources, try including
'golded-plus/cfgs/config/charsets.cfg' in your golded.conf and
see if that helps or not.

Already have that since ever.

For that group I have:

GROUP B
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP437 LATIN-2 asc_il2.chs
XLATCHARSET LATIN-2 CP437 il2_asc.chs
XLATIMPORT CP437
XLATIMPORT CP437
XLATLOCALSET LATIN-2
MSGLISTWIDESUBJ YES
ENDGROUP

Using UTF-8 in putty, having LANG=cs_CZ.utf8 in bash, startin golded:
luit -encoding 'ISO-8859-2' ./gedlnx -f

(because GROUP A we have ISO-8859-2 as agreed coding)

As I wrote, I have issue in GROUP B, GOLDED here...

OK. Your case is actually simpler than I thought. You should have zero issues with pseudo-graphics.

Try to set LANG to cs_CZ.ISO8859-2 and that will solve your issue! No need to set it for the whole system. Just for golded session.

$ LANG=cs_CZ.ISO8859-2 luit -encoding 'ISO-8859-2' ./gedlnx -f

Your problem is that luit converts symbols from 8859-2 to UTF, but ncurses tries to work in UTF-8 mode because you have LANG=cs_CZ.utf8.

In my case I have separate session in Putty with KOI8-R. And run golded like this:

LANG=ru_RU.koi8r gedlnx -C<myconfig>

And have no issues with pseudo-graphics. But luit works too, just tried it.

Vitaliy

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

Hello Nicholas.

07 Mar 24 17:11, you wrote to Karel Kral:

For that group I have:

GROUP B
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP437 LATIN-2 asc_il2.chs
XLATCHARSET LATIN-2 CP437 il2_asc.chs
XLATIMPORT CP437
XLATIMPORT CP437
XLATLOCALSET LATIN-2
MSGLISTWIDESUBJ YES
ENDGROUP

Are you using the wrong translation table? I think you should be using cp437 -> il2, rather than ascii -> il2.

Most probably he does because it works for him prior to my last changes. So I assume that text conversion performed correctly.

Vitaliy

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

On Thu, 7 Mar 2024 23:27:32 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

Are you using the wrong translation table? I think you should be using
cp437 -> il2, rather than ascii -> il2.

Most probably he does because it works for him prior to my last changes. So I assume that text conversion performed correctly.

By his previous messages, I'm led to believe his hasn't been working
properly for awhile.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Vitaliy!

07 Mar 24 17:08, you wrote to me:

Try to set LANG to cs_CZ.ISO8859-2 and that will solve your issue! No
need to set it for the whole system. Just for golded session.

$ LANG=cs_CZ.ISO8859-2 luit -encoding 'ISO-8859-2' ./gedlnx -f

Just did, but no improvement. Would it be possible that old messages are alreadu scrambled and I have to wait for new examples?

Your problem is that luit converts symbols from 8859-2 to UTF, but
ncurses tries to work in UTF-8 mode because you have LANG=cs_CZ.utf8.

I am not sure that is just my XLAT setup or BASH env. Interesting is, that it is only subject (message is OK). What is difference for XLAT in Subj and in Message? Why one UTF-8 is OK a different is not (UTF-8 4 against UFT-8 2)?

And there was another collegue who has same issue (assume different setup).

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello Nicholas!

07 Mar 24 17:11, you wrote to me:

Are you using the wrong translation table? I think you should be using cp437 -> il2, rather than ascii -> il2.

I do not have xlat file like that.

Point is that in group B there I expect only English and old fashioned ascii 127 anyway.

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

On Fri, 8 Mar 2024 13:33:28 +0100, Karel Kral -> Nicholas Boel wrote:

Are you using the wrong translation table? I think you should be using
cp437 -> il2, rather than ascii -> il2.

I do not have xlat file like that.

Point is that in group B there I expect only English and old fashioned ascii 127 anyway.

This is from one of your previous messages, just so I stay on track with
what your settings are:

"Using UTF-8 in putty, having LANG=cs_CZ.utf8 in bash, startin golded:
luit -encoding 'ISO-8859-2' ./gedlnx -f"

You might want to try iso-8859-2 in PuTTY, also, rather than UTF-8. Then
try the command line that Vitaliy recommended to use?

If that doesn't work, you could try using this as well and see if it
does something different for you:

xlatcharset cp437 utf-8 437_u8.chs

If that .chs file isn't in your xlat directory, I believe you can grab
it from Golded sources on github.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Nicholas!

08 Mar 24 05:59, you wrote to me:

You might want to try iso-8859-2 in PuTTY, also, rather than UTF-8.
Then try the command line that Vitaliy recommended to use?

Just tested. No improvement for GOLDED, even worse in shell.

xlatcharset cp437 utf-8 437_u8.chs

If that .chs file isn't in your xlat directory, I believe you can grab
it from Golded sources on github.

Got that file, included into golded.cfg - for UTF-8. No improvement.

I also played with EDITREPLYRE, but also no change.

As it is about 4 characters, I think is bug in golded related to "Re: ". I have no issue with other messages (even using local czech characters, including quoting). In total I see everything OK, except few messages in International echos.

E.g. replying to you - you can see Subj. is OK.

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello Karel.

08 Mar 24 07:30, you wrote to me:

Try to set LANG to cs_CZ.ISO8859-2 and that will solve your
issue! No need to set it for the whole system. Just for golded
session.

$ LANG=cs_CZ.ISO8859-2 luit -encoding 'ISO-8859-2' ./gedlnx -f

Just did, but no improvement. Would it be possible that old messages
are alreadu scrambled and I have to wait for new examples?

Could you please make sure that your system actually has such locale?

What does it show if you run:
LANG=cs_CZ.ISO8859-2 locale

Also try to run:
locale -a

If it doesn't show that locale - you need to install or generate it. Each linux distro has own way to do it, but that's easy to google.

Your problem is that luit converts symbols from 8859-2 to UTF,
but ncurses tries to work in UTF-8 mode because you have
LANG=cs_CZ.utf8.

I am not sure that is just my XLAT setup or BASH env. Interesting is,
that it is only subject (message is OK). What is difference for XLAT
in Subj and in Message? Why one UTF-8 is OK a different is not (UTF-8
4 against UFT-8 2)?

It could be both. Could you please show your xlat setup?

BTW, luit works for me. Only difference is that my FidoNet charset is KOI8-r.

As for UTF - it's not supported and might "work" if you do some weird setup, but I'd not count on it. Better work in one-byte locales like cp437 or ISO8859-2 in your case.

And there was another collegue who has same issue (assume different setup).

I totally understand you. I spend several days before my system started to work OK. Will try to resolve your issues. :)

Vitaliy

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

Hello Vitaliy!

09 Mar 24 12:44, you wrote to me:

Could you please make sure that your system actually has such locale?

What does it show if you run:
LANG=cs_CZ.ISO8859-2 locale

.. LANG=cs_CZ.ISO8859-2 locale
LANG=cs_CZ.ISO8859-2
LC_CTYPE="cs_CZ.ISO8859-2"
LC_NUMERIC="cs_CZ.ISO8859-2"
LC_TIME="cs_CZ.ISO8859-2"
LC_COLLATE="cs_CZ.ISO8859-2"
LC_MONETARY="cs_CZ.ISO8859-2"
LC_MESSAGES="cs_CZ.ISO8859-2"
LC_PAPER="cs_CZ.ISO8859-2"
LC_NAME="cs_CZ.ISO8859-2"
LC_ADDRESS="cs_CZ.ISO8859-2"
LC_TELEPHONE="cs_CZ.ISO8859-2"
LC_MEASUREMENT="cs_CZ.ISO8859-2"
LC_IDENTIFICATION="cs_CZ.ISO8859-2"
LC_ALL=

Also try to run:
locale -a

.. locale -a | grep cs_CZ
cs_CZ
cs_CZ.iso88592
cs_CZ.utf8

It could be both. Could you please show your xlat setup?

GOLDED is showed as Group B
in cfg (this is the latest, changed also based on the latest advice)

GROUP B
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP437 LATIN-2 asc_il2.chs
XLATCHARSET LATIN-2 CP437 il2_asc.chs
XLATCHARSET CP437 UTF-8 437_u8.chs
XLATIMPORT CP437
XLATIMPORT CP437
XLATLOCALSET LATIN-2
MSGLISTWIDESUBJ YES
ENDGROUP

BTW, luit works for me. Only difference is that my FidoNet charset is KOI8-r.

It is working for me in local, czech echomail.

As for UTF - it's not supported and might "work" if you do some weird setup, but I'd not count on it. Better work in one-byte locales like
cp437 or ISO8859-2 in your case.

Where I am reading, usualy they use English. Then pure ASCII should be enough. And I would be OK even for some exceptional scrambled messages. But why some Subject lines are impacted? I see whole message OK, just that line has copied over 4 bytes. Always the same position.

I totally understand you. I spend several days before my system
started to work OK. Will try to resolve your issues. :)

No problem. Have that since years. I just started to wonder if somebody else can see that. Take is as the lowest prio.

I checked code already, for some "quick win" - but I am not c-guy = nothing found by myself.

Thank you for any help.

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)