Hello Michiel.

04 Mar 24 08:42, you wrote to me:

 MvdV>>> Perhaps the best strategy is to have Golded alway use UTF-8
 MvdV>>> internally. Almost everyone else does these days...

 VA>> That would be perfect. It only takes huge amount of effort.
 VA>> Especially with keeping code backward compatible with systems,
 VA>> which may not have Unicode support. I keep thinking about it and
 VA>> looking for possible ways to implement.

 MvdV> Backwards compatibility is nice but there always comes a point that it
 MvdV> gets in the way of progress and it has to be dropped. Are you thinking
 MvdV> about the DOS version? If so I say, forget about it. Freeze the DOS
 MvdV> version, the small minority that still uses DOS will have to make do
 MvdV> with what they have fo the rest of the life of DOS.

We've been thinking about that option.

 MvdV> Another way may be to not use UTF-8 internally but use two byte
 MvdV> widechrs everywhere and simple store the raw unicode code point.
 MvdV> Conversion to and from code point to UTF-8 is simple. That will limit
 MvdV> the use to the first 65535 code points, but that might be enough for
 MvdV> the remaining life of Fidonet. OTOH, that is almost the same as what
 MvdV> Window XP did. It used UTF-16 internally and Microsoft now regrets
 MvdV> that.

Best possible way is to use UTF-8 for all strings inside and only convert text when read/write from/to message base and to screen. And even if drop DOS support - need to take into account OS specifics for Unicode. As long as GoldEd uses fixed size buffers in many places - that's huge refactoring. Better to replace it with std::string almost everywhere.

 VA>> For example function, which splits message to lines is almost
 VA>> 1000 lines long! It has variables, used in multiple places, it
 VA>> not only splits the message, but guess charset, do recoding and
 VA>> other fun stuff.

 MvdV> Wauw!

That's one of the reasons, why progress is slow.

Vitaliy

--- GoldED+/LNX 1.1.5-b20240223