home bbs files messages ]

Just a sample of the Echomail archive

<< oldest | < older | list | newer > | newest >> ]

 Message 2222 
 Vitaliy Aksyonov to Nicholas Boel 
 Re: Need volonteers to test another patc 
 02 Mar 24 09:13:34 
 
REPLY: 1:154/10 65dfd0bc
MSGID: 1:104/117 65e354b9
CHRS: US-ASCII 2
TZUTC: -0700
TID: hpt/lnx 1.9 2022-07-03
Hello Nicholas.

28 Feb 24 18:33, you wrote to me:

 VA>> I played with your configuration and have a good and bad news for
 VA>> you.

 VA>> Good:
 VA>> - I reproduced your issue.
 VA>> - GoldEd correctly converts pseudo-graphics from cp437 to utf-8.

 NB> Well, it did. Until you reverted those changes. :(

Most probably it was some combination which made it looking almost correct. I
think that screen may be the reason you saw pseudo-graphics more or less
correctly. Remember those line wraps? That happens because GoldEd converts
those symbols to UTF-8 first. All pseudo-graphics symbols represented as 3
bytes. So that line become 3 times longer in bytes. Then GoldEd tries to split
message to lines and it uses bytes! not symbols. That's why it splits the line
in the middle of those pseudo-graphics. Even worse, it may tear apart one
UTF-8 symbol to two lines and it will be displayed incorrectly.

GoldEd cannot work correctly with multibyte sequences. And even if it looks
"correct", it's just because most English letters has same codes in cp437 and
UTF-8.

If you want to keep using UTF-8, I may only suggest to find version, which
"works" for you and stick to it.

Until full UTF-8 support implemented in GoldEd (if that ever happen), don't
expect it to work correctly, sorry.

 VA>> Bad:
 VA>> - GoldEd does not support unicode. Even if you compile it with
 VA>> ncursesw, it still uses non unicode versions of functions to
 VA>> print text. That's why you see those escape sequences instead of
 VA>> pseudo-graphics symbols.

 NB> Something happened recently where it made it quite a bit worse. I was
 NB> reading utf-8 Cyrillic, Greek, Japanese, Chinese, etc just fine in
 NB> Golded until the most recent version.

I understand, that it might "work", but it was pure luck.

 NB> What changed with the ncurses init that was reverted?

First commit I did - changed order when ncurses initializes to be able to
print some text, which doesn't use ncurses functions. That is used, when you
run it with "-INSTALL". Before my first change with ncurses, that text was not
displayed. I tried to fix that. But it caused some issues to dome sysops and
what I did in recent commit - revert it back to what it was before commit
8e9f3518ac9b3b32676e7b7563e92cc44e7b5ba7.

 NB> And why does that change affect me opposite of a cp437 locale user?

Your setup is not supported and it's hard to say why it even works.
Unfortunately I'm not big ncurses expert and hard to say what may go wrong.

 NB> If all I'm doing is translating from cp437 to utf-8 (or anything to
 NB> utf-8) I should still be able to read it properly, as I have been..
 NB> until recently. Whatever you were doing with ncurses init helped me. I
 NB> was able to read utf-8 messages perfectly fine. Almost every single
 NB> "Merry Christmas" or "Happy New Year" Michiel posts yearly (except
 NB> maybe a 2 or 3) were perfectly readable in Golded. The latest version
 NB> they are not.

Let me try to explain. Some UTF-8 characters have more than one byte. But
GoldEd "prints" them to screen one by one. Also it applies some attributes. It
uses non-unicode versions of ncurses functions and if that byte looks like
special character to ncurses, it escapes it. That's why you see those weird
character sequences with ~.

 VA>> I still suggest you to use one-byte locale for GoldEd. And
 VA>> remember, you don't need to switch whole system to that locale,
 VA>> because in Linux locale is a property of a process. So you may
 VA>> have UTF-8 everywhere and cp437 for GoldEd. Most of terminals
 VA>> (including Putty) support different charsets.

 NB> I'll pass on the suggestion :). I'll just keep using the last version
 NB> that worked for me (minus a couple badly displayed ascii line
 NB> characters, and keep testing newer versions to see if I ever get the
 NB> display back that I lost. :)

It's your choice. Just be aware, that if it works - it's just pure luck and
don't expect it to last. Until we implement UTF-8 support. It may take years.
Or never happen. It's not so easy to do it with backward compatibility wih all
older systems like DOS or OS/2.

 VA>> Another option - is to use external editor, but that won't help
 VA>> you with message reader.

 NB> I already do this (I have always used nano with Golded). Viewing and
 NB> writing in an external editor has never been a problem. Until
 NB> recently, only reading became an issue. So the whole time it was
 NB> working for me you actually broke something instead? :((

I'm sorry about that, but it's not much we can do right now.

Vitaliy

--- GoldED+/LNX 1.1.5-b20240223
 * Origin: Aurora, Colorado (1:104/117)
SEEN-BY: 15/0 18/200 50/109 90/1 104/117 105/81 106/201 128/260 129/305
SEEN-BY: 135/225 153/7715 218/700 226/30 227/114 229/110 112 113 206
SEEN-BY: 229/307 317 400 426 428 470 664 700 266/512 280/464 5555
SEEN-BY: 282/1038 291/111 292/854 301/1 320/219 322/757 342/200 396/45
SEEN-BY: 460/16 58 256 1124 5858 463/68 467/888 633/280 712/848 3634/12
SEEN-BY: 5000/111 5001/100 5005/49 5015/46 5020/828 846 1042 4441
SEEN-BY: 5030/49 5054/8 30 5061/133 5075/128 5083/444 5090/958
PATH: 104/117 5020/1042 460/58 229/426


<< oldest | < older | list | newer > | newest >> ]

(c) 1994,  bbs@darkrealms.ca