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