emacs-bidi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [emacs-bidi] state of BIDI within stable GNU emacs (UTF8) nikud


From: Eli Zaretskii
Subject: Re: [emacs-bidi] state of BIDI within stable GNU emacs (UTF8) nikud
Date: Tue, 29 Nov 2005 23:32:20 +0200

> Date: Tue, 29 Nov 2005 05:16:43 -0600
> From: Gregg Reynolds <address@hidden>
> CC: address@hidden
> 
> > It's hard to say, since you didn't show the commands you used to build
> > Emacs; please always do that when you report problems.
> > 
> Sorry 'bout that.  I ran "make bootstrap" after cvs'ing the emacs-bidi 
> branch.

Thanks for working on this.

> Turns out that function "bidi_dump_cached_states" in bidi.c prints to 
> stderr, but stdio is only included #ifdef TEST_STANDALONE.  Since the 
> function doesn't seem to be used, I just #if 0'ed it out and "make 
> bootstrap" succeeded.

I'd prefer a cleaner solution, one that doesn't disable the standalone
configuration.  How about if stdio was included unconditionally? it
cannot hurt, I think.

Also, if you can, please post context diffs of the changes you
suggest, as that makes fixing the problems in the CVS much easier.

> Regarding TEST_STANDALONE, I don't see any make targets or anything 
> obvious for doing that.  Do you have any tools/test stuff remaining for 
> this?

Yes, I do: that's how I tested and debugged the code outside Emacs.
But I don't see any need to make it part of Emacs, since that testing
is already done, and the code passes it with flying colors.  Now it
needs to be tested inside Emacs, which is a different environment,
since, e.g., the display engine not always renders complete paragraphs
or even complete lines, and the UAX#9 algorithm depends heavily on
notions such as ``paragraph direction'' and ``first strong
character''.

> What would you think about moving your TEST_STANDALONE code out of 
> bidi.c and in to a separate driver program?

What for?  It doesn't hurt anything to have the test code there, and
keeping them together makes sure the testing code will not be lost.

> Also, would it make sense to use a logging framework like Log4c
> (http://log4c.sourceforge.net/) instead of simulate_display?

It's just a simple test driver, I don't see any justification for
sophisticated logging.  All I needed to see is whether reordering does
what UAX#9 mandates, that's all.

> I'm also looking at unit test framework that I think might be useful: 
> CUnit (http://cunit.sourceforge.net/index.html), which is a GPL'ed 
> JUnit-like framework for C.

Emacs doesn't currently have any test suite (mainly because the main
purpose of an editor is to display the buffers, and detecting display
bugs automatically is not easy).  So something as elaborate as CUnit
would be a waste of time if we do that for bidi code alone.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]