aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorJarno Mäkipää <jmakip87@gmail.com>2019-03-28 08:32:36 +0200
committerRob Landley <rob@landley.net>2019-03-28 09:50:03 -0500
commit6ca648cc1f55eecfde535a7b78b57797b8c227d6 (patch)
tree013528a2fad1743c97aefa96366549c9b3a94b48 /README
parent7c1601c2faec14b81c84539a64ba662cfe2b0d62 (diff)
downloadtoybox-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