diff options
author | Jarno Mäkipää <jmakip87@gmail.com> | 2019-03-28 08:32:36 +0200 |
---|---|---|
committer | Rob Landley <rob@landley.net> | 2019-03-28 09:50:03 -0500 |
commit | 6ca648cc1f55eecfde535a7b78b57797b8c227d6 (patch) | |
tree | 013528a2fad1743c97aefa96366549c9b3a94b48 /README | |
parent | 7c1601c2faec14b81c84539a64ba662cfe2b0d62 (diff) | |
download | toybox-6ca648cc1f55eecfde535a7b78b57797b8c227d6.tar.gz |
vi.c improved utf-8 support
Now calculates utf-8 rune width properly before trying to print on screen.
works with test1.txt and test2.txt on tests/files/utf8 folder with
0x0300-0x036F combining chars
Uses mbtowc and wcwidth to calculate width of rune. These both should be
implemented on c runtime that conforms POSIX-1.2001. Different c
runtimes might have different level of support to combining char
ranges etc...
I think there is no standard way to calculate utf-8 rune width without
converting it first to widechar. And i think conversion to widechar just
to calculate width is silly, since all write calls can be done with utf8
directly (on utf8 locales ofc), but in order to calculate them yourself
without pointless conversion, one would need to write variable byte lookup
array for binary searching weird ranges and make sure it works with big-endian
systems too...
By the way running ./watch ./cat tests/files/utf8/japan.txt does not print the
text for some reason, but other test data does... I was checking how
well original crunch_str works and noticed it.
-Jarno
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions