Subj : Re: Changes in golded+ sources
To : Nicholas Boel
From : Vitaliy Aksyonov
Date : Sun Nov 05 2023 07:52 am
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?
