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