MSGID: 1:154/10 65e48d3c
REPLY: 1:104/117 65e40f96
PID: Smapinntpd/Linux 2.0 b20240302
CHRS: UTF-8 4
TZUTC: -0600
TID: hpt/lnx 1.9 2024-02-05
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
 * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
SEEN-BY: 15/0 18/200 90/1 103/705 105/81 106/201 120/616 123/10 124/5016
SEEN-BY: 128/260 129/305 135/225 153/757 7715 154/10 30 40 50 700
SEEN-BY: 203/0 218/700 220/90 221/0 6 226/18 30 227/114 229/110 112
SEEN-BY: 229/113 206 307 317 400 426 428 470 664 700 240/1120 5832
SEEN-BY: 266/512 280/464 5003 5555 282/1038 291/111 292/854 8125 301/1
SEEN-BY: 310/31 320/219 322/757 341/66 234 342/200 396/45 423/120
SEEN-BY: 460/16 58 256 1124 5858 467/888 633/280 712/848 770/1 2320/105
SEEN-BY: 3634/12 5020/400 1042 5054/30
PATH: 154/10 280/464 460/58 229/426