REPLY: 1:154/10 65483ecd   
   MSGID: 1:104/117 654854ca   
   CHRS: CP866 2   
   TZUTC: -0700   
   TID: hpt/lnx 1.9 2022-07-03   
   �ਢ¥â, Nicholas!   
      
   05 Nov 23 19:03, âë ¯¨á «( ) ¬­¥:   
      
    VA>> Hi. Yes. "Zero conversion" change broke it. Anyway it's used   
    VA>> incorrectly now. Because in the code GoldED uses level from   
    VA>> conversion table, but it has nothing to do with charset level   
    VA>> itself.   
      
    VA>> I'm still working on encoding conversions code and will do more   
    VA>> changes. I will try to restore that behavior for backward   
    VA>> compatibility.   
      
    NB> Thank you!   
      
   My plan is to enhance conversion code which uses iconv in linux builds. And   
   then you won't need any translation tables for charsets known by iconv. It   
   will take some time, because changes are not so small.   
      
    VA>> Just in case - you understand, that GoldEd can't properly work   
    VA>> with UTF-8 local charset if any international character used?   
      
    NB> Do you have any examples?   
      
   GoldEd charset translation code can translate one byte encodings to multibyte,   
   but not the opposite.   
      
   So if you write your message in CP437 and export it to UTF-8 - it will work   
   fine if such translation table exists.   
   Now imagine that your local charset is CP437 and message is in UTF-8. That   
   won't work because translation tables size is only 256 bytes and UTF-8 code   
   may have up to 6 bytes per code point.   
      
    NB> As I mentioned, I'm using Golded with tmux, and besides CP437 ANSI or   
    NB> 'high ascii' characters (which is a little better when I use   
    NB> 'xlatimport CP437', I'm seeing characters like cyrillic, umlauts,   
    NB> dieresis, etc just fine. Granted, once you get into Chinese or   
    NB> Japanese, there may be issues. But I haven't seen much if any of that   
    NB> in Fidonet, so I'm not too worried about it. When posting using an   
    NB> external editor, I am only limited to what the font I use actually   
    NB> supports. Otherwise I can write the previously mentioned things just   
    NB> fine as well.   
      
   External editor solves some issues, but not all. Would be cool to have UTF-8   
   used for internal string representation, but that's huge work.   
      
   What is your XLatLocalSet, XLatImport, XLatExport?   
      
   Best regards,   
   Vitaliy Aksyonov.   
      
   --- GoldED+/LNX 1.1.5-b20231030   
    * Origin: Aurora, Colorado (1:104/117)   
   SEEN-BY: 1/123 10/0 1 15/0 18/200 50/109 80/1 90/1 102/401 103/1 705   
   SEEN-BY: 104/117 105/81 106/201 123/131 129/305 153/7715 154/10 214/22   
   SEEN-BY: 218/0 1 215 601 700 720 840 860 870 880 930 221/1 6 226/30   
   SEEN-BY: 227/114 229/110 112 113 206 307 317 400 426 428 452 470 664   
   SEEN-BY: 229/700 240/1120 266/512 280/464 5555 282/1038 291/111 292/854   
   SEEN-BY: 301/1 113 123 812 305/3 317/3 320/219 322/757 335/364 341/66   
   SEEN-BY: 342/200 396/45 460/58 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 5061/133 5075/128 5083/444 5090/958   
   PATH: 104/117 5020/1042 301/1 218/700 229/426