> Date: Wed, 30 Nov 2005 15:44:16 +0900 > From: Martin Duerst <[EMAIL PROTECTED]> > Cc: [email protected] > > >I built many small test cases which use every feature. To that, I > >added a test case for every bug I've found during debugging. As for > >embedding, it's sufficient to test several levels, no need to test all > >61 of them. > > To some extent, this sounds as if the code is actually ready for > practical use as long as it's not for terribly important stuff > where loss of data would hurt seriously. > > Is that understanding okay?
Well, yes and no. Yes, because it was extensively tested as a standalone application. No, because, when it is called by the display engine, it's quite possible that the initial conditions (i.e., the place where redisplay starts to walk the buffer) is something other than what I had in mind when I designed and coded the algorithm, which could easily cause the code to become confused, since the Unicode algorithm needs to resync at the paragraph/line boundaries, find the first strong directional character, etc. I think someone told me that the bidi-enabled version of Emacs crashes fairly quickly after you turn on the bidi display flag. (The crashes are actually deliberate calls to `abort' when the code finds itself in a situation that wasn't supposed to happen, and Emacs always auto-saves everything before it dies, so you aren't supposed to lose any important work.) So some real debugging is, in fact, in order. The good news are that the bidi reordering code is not invoked unless you turn on the bidi display flag (the buffer-specific variable enable-bidi-display, which is nil by default). _______________________________________________ emacs-bidi mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-bidi
