REPLY: 1:154/10 6546b010   
   MSGID: 1:104/117 6547ac1f   
   CHRS: US-ASCII 2   
   TZUTC: -0700   
   TID: hpt/lnx 1.9 2022-07-03   
   Hello Nicholas.   
      
   04 Nov 23 10:48, you wrote to golded+ inspector:   
      
    NB> Wondering if any one of these commits changed something in regards to   
    NB> a workaround a small (probably very small) handful of people have been   
    NB> using since about as far back as I can remember.   
      
    NB> I'm currently using all available conversions (xlatcharset) to utf-8,   
    NB> with:   
      
    NB> xlatimport utf-8   
      
    NB> This has been swapped back and forth between cp437 and utf-8. It seems   
    NB> most messages without a CHRS kludge are in the CP437 realm, but having   
    NB> a utf-8 terminal still doesn't display a lot of cp437 characters   
    NB> properly even with the conversion tables, and I understand why (256   
    NB> character limit).   
      
    NB> xlatexport utf-8   
    NB> xlatlocalset utf-8   
      
    NB> Then I'm using a conversion table simply named utf_utf.chs with the   
    NB> following:   
      
    NB> [begin utf_utf.chs]   
      
    NB> ; This file is a charset conversion module in text form.   
    NB> ;   
    NB> 100000          ; ID number (when >65535, all 255 chars will be   
    NB> translated) 0               ; version number ; 4               ; level   
    NB> number ; UTF-8 UTF-8 ; END   
      
    NB> [end utf_utf.chs]   
      
    NB> This was only to trick Golded into using the 'CHRS: UTF-8 4' kludge,   
    NB> otherwise it would always post with 'CHRS: UTF-8 2', which is   
    NB> basically irrelevant. This makeshift conversion table doesn't seem to   
    NB> be working any more for that purpose.   
      
    NB> Using tmux with Golded, and an external editor (nano or vim) this has   
    NB> allowed me to read and write utf-8 messages properly for quite some   
    NB> time (and really, nothing has changed recently except the CHRS kludge.   
    NB> ;))   
      
    NB> I guess, instead of asking for this workaround to work again (if any   
    NB> of the above has actually done something to break/fix this; however   
    NB> you want to look at it), maybe I should be asking the question to   
    NB> actually change/fix the issue instead.   
      
    NB> When posting outgoing messages with 'xlatexport utf-8' is there an   
    NB> easy way to hard code using the proper 'CHRS: UTF-8 4' kludge instead   
    NB> of it using the level 2 parameter?   
      
   Hi. Yes. "Zero conversion" change broke it. Anyway it's used incorrectly now.   
   Because in the code GoldED uses level from conversion table, but it has   
   nothing to do with charset level itself.   
      
   I'm still working on encoding conversions code and will do more changes. I   
   will try to restore that behavior for backward compatibility.   
      
   Just in case - you understand, that GoldEd can't properly work with UTF-8   
   local charset if any international character used?   
      
   Vitaliy   
      
   --- GoldED+/LNX 1.1.5-b20231030   
    * Origin: Aurora, Colorado (1:104/117)   
   SEEN-BY: 1/123 15/0 18/200 50/109 90/1 103/705 104/117 105/81 106/201   
   SEEN-BY: 123/131 124/5016 129/305 153/757 7715 154/10 203/0 218/700   
   SEEN-BY: 221/0 226/30 227/114 229/110 112 113 206 307 317 400 426   
   SEEN-BY: 229/428 452 470 664 700 240/1120 5832 266/512 280/464 5003   
   SEEN-BY: 280/5555 282/1038 291/111 292/854 8125 301/1 305/3 310/31   
   SEEN-BY: 317/3 320/219 322/757 341/66 234 342/200 396/45 423/120 460/16   
   SEEN-BY: 460/58 256 1124 5858 463/68 467/888 633/267 280 410 412 418   
   SEEN-BY: 633/420 509 2744 712/848 770/1 3634/12 5000/111 5001/100   
   SEEN-BY: 5005/49 5015/46 5020/400 828 846 1042 4441 5030/49 5054/8   
   SEEN-BY: 5054/30 5061/133 5075/128 5083/444 5090/958   
   PATH: 104/117 5020/1042 460/58 280/464 633/280 229/426