Hello Vitaliy,

On Sunday November 05 2023 19:31, you wrote to me:

 VA> จจจจจจ, Nicholas!

 VA> 05 Nov 23 19:03, จจ จจจจจ(จ) จจจ:

I may not be able to read some of the above, but it sure looks nice! ;)

 VA> My plan is to enhance conversion code which uses iconv in linux
 VA> builds. And then you won't need any translation tables for charsets
 VA> known by iconv. It will take some time, because changes are not so
 VA> small.

Would you suggest going back to the b20231028 code then until you're done messing around with it?

 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?

 VA> GoldEd charset translation code can translate one byte encodings to
 VA> multibyte, but not the opposite.

 VA> So if you write your message in CP437 and export it to UTF-8 - it will
 VA> work fine if such translation table exists. Now imagine that your
 VA> local charset is CP437 and message is in UTF-8. That won't work
 VA> because translation tables size is only 256 bytes and UTF-8 code may
 VA> have up to 6 bytes per code point.

Ah yes. Understood. My local charset is UTF-8. Sometimes I try to do translations of incoming messages, but that's about it.

 VA> External editor solves some issues, but not all. Would be cool to have
 VA> UTF-8 used for internal string representation, but that's huge work.

It solves most, at least for Fidonet messaging. Most messages are US-ASCII, CP437/850, CP866, or UTF-8, which I can handle here just fine.

 VA> What is your XLatLocalSet, XLatImport, XLatExport?

All are currently set to UTF-8. However, sometimes I like to test XLatImport CP437. It helps on some messages, but since my locale is completely UTF-8 it isn't perfect, usually when related to ANSI escape sequences.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- GoldED+/LNX 1.1.5-b20231030