Subj : Re: Need volonteers to test another patch
To : Michiel van der Vlist
From : Vitaliy Aksyonov
Date : Mon Mar 04 2024 07:58 am
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.
