https://bugs.kde.org/show_bug.cgi?id=378124
m...@arccos-1.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |m...@arccos-1.net
--- Comment #3 from m...@arccos-1.net ---
(In reply to Kurt Hindenburg from comment #2)
> I'm open to suggestions to avoid all these width issues.
First thing Konsole needs is to change internal character representation from
UTF16 to UTF32. This will allow to properly handle code points above 0xffff
(right now, they are all assumed to be wide and non-combining). QChar::is*()
and wcwidth(), even the one implemented in Konsole, already support UTF32
characters. Nice thing is that Character class won't change size - it uses 13
bytes aligned to 16, so after change it will be 15 bytes aligned to 16.
I think glibc's wcwidth() would be nice as a source of character widths:
- Unicode 10 since 2.26 (released on february 2017, available in e.g. Kubuntu
17.10).
- Most terminal applications probably use it, so widths would match.
- Less code to maintain.
Possible disadvantages:
- Qt's QChar::is*() can use another Unicode version, potentially slightly
incompatible with glibc's one. Solution: use iswctype() instead.
- Unicode 8 (or older) on systems with older glibc.
- Lack of customization, like selecting Unicode version (e.g. when connecting
to remote systems with older glibc), or changing width of ambiguous characters,
but there is no such feature right now.
I've already modified Konsole to use UTF32 and glibc's wcwidth(), I just have
to clean it up a bit before creating review request.
--
You are receiving this mail because:
You are watching all bug changes.
