<div dir="ltr"><div dir="ltr"><div>Now calculates utf-8 rune width properly before trying to print on screen.</div><div>works with test1.txt and test2.txt on tests/files/utf8 folder with</div><div>0x0300-0x036F combining chars</div><div><br></div><div>Uses mbtowc and wcwidth to calculate width of rune. These both should be</div><div>implemented on c runtime that conforms POSIX-1.2001. Different c</div><div>runtimes might have different level of support to combining char</div><div>ranges etc...</div><div><br></div><div>I think there is no standard way to calculate utf-8 rune width without</div><div>converting it first to widechar. And i think conversion to widechar just</div><div>to calculate width is silly, since all write calls can be done with utf8</div><div>directly (on utf8 locales ofc), but in order to calculate them yourself</div><div>without pointless conversion, one would need to write variable byte lookup</div><div>array for binary searching weird ranges and make sure it works with big-endian</div><div>systems too...</div><div><br></div><div>By the way running ./watch ./cat tests/files/utf8/japan.txt does not print the</div><div>text for some reason, but other test data does... I was checking how</div><div>well original crunch_str works and noticed it.</div><div><br></div><div>-Jarno</div><div><br></div></div></div>