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