Me: >>> If I kick off the both test/editor to read misc/cp1252*.txt I get: >>> >>> 1.3: cp1252.txt: >>> missing columns 128 onward, ie no 8-bit chars, >>> and missing the right wall of the table too >>> [I've switched workspaces and it has hung too]
Ian: >> Well, for the record, I get the same effect, i.e. cursor into the >> "bad" text causes editor to hang when displaying cp1252.txt, when >> testing on all of: WinXP, ubuntu-9.10, OSX 10.4.11 >> >> So... I guess it's our bug in fltk and not some X11 or similar... Me: > I've just opened STR 2348: http://www.fltk.org/str.php?L2348 > "test/editor fails to display misc/cp1252.txt and can hang" > > Unfortunately, it looks like this problem didn't exist back in r7400 > before the big refactoring, but was in the last snapshot, r7513, so > it looks like something got zapped in the big refactoring. > > The question now is: do we revert and rework the changes for STR-2158 > into the "crappier-but-working" code, or do we stick with, and debug, > the current "less-cruft-but-failing" code? I've been trying to debug the "less-cruft-but-failing" code, and at first I thought the utf-8 aware code was confused by the raw 0x80-0x9f control characters, and getting out of sync as it skips to and fro trying to find the start/end of the utf-8 sequence. But then I ran the editor demo in ddd, caused it to lock/hang, and then interrupted it, and found it was in a low-level fl_width() call. So methinks there's a missing 0-terminator on a string, or a buffer overrun somewhere. It might take some time for me to track it down. D. PS. To revert or not to revert, that is still the question! _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
