On Sun, 3 Mar 2024 04:42:52 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

 VA> I played little bit more with the code and different settings and found
 VA> what was the difference between those two versions.

 VA> First - you use "wide" ncurses - ncursesw. I use ncurses.
 VA> Second. GoldEd incorrectly initializes ncurses in reverted version (like
 VA> it was before I started to make any changes in GoldEd code). ncurses
 VA> documentation explicitly says that before call initscr(), locale has to
 VA> be set with setlocale. Otherwise it will use incorrect settings. Most
 VA> probably plain C locale. I kinda get picture very similar to yours.

For the record, I don't compile golded with WIDE_NCURSE=1. I have tried
it in the past, but I don't see much, if any difference. However, I have
also realized that in my distro (Archlinux) I don't have to install two
separate packages for that, either. ncurses comes with ncursesw
included. Is that maybe the difference?

 VA> Did you have an issue with non-English chars when scrolling the message?

Non-english characters usually display OK, and sometimes when you scroll
the message, some of them (usually moreso the line and block drawings
converted from cp437) will gain a red background with green "^"
characters) or as you say below, corrupts. Using page down instead of
line scrolling keeps the characters in tact, though.

 VA> What I see in UFT-8 terminal now - most of unicode text displayed
 VA> correctly and pseudo-graphic too. Only pseudo-graphics lines broken
 VA> similar to yours. And when I scroll text down - it corrupts.

Yes, I see this too. However, try using page down instead of the down
arrow key. Maybe that will point you in a direction as to how both key
presses are handled and you may be able to fix that as well!

As for the pseudo-graphics wrapped to the next line, I have a (probably
dumb) question about this: If the pseudo graphics were originally cp437
(single byte) and translated to utf-8, once they are translated are they
now multiple bytes per character?

If "UTF-8 uses 1 to 4 bytes to encode a single character", I guess what
I'm wondering is if the character was 1 byte to begin with, why wouldn't
it stay 1 byte when translated to utf-8? Or is it because those
_specific_ characters when in utf-8 are already multiple bytes?

 VA> If you may try to add one line of code to latest master and try it -
 VA> that would be helpful.

 VA> goldlib/gcui/gkbdbase.cpp
 VA> line 149, right before initscr add this:

 VA> setlocale(LC_ALL, "");

 VA> If that gives you expected result - I'll push this change to master.

It worked! Or at least it's back to the way it was, which is a good thing!

 VA> Hope you still want to dig this. :)

Definitely! I appreciate you willing to help, even though we both know
it's broken in more ways than one. I do understand that it is not
currently (and has never been) supported, but if we can make it "kind
of" work while not affecting others, I'm all for it!

I would rather have a somewhat-working program than a non-working
program. :)

THANK YOU!

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