Re: [emacs-bidi] Summary of bidi branch?

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Date: Wed, 28 Mar 2007 16:11:25 +0200
> 
> is there somewhere a summary of where the bidi branch stands nowadays?

Not that I know of, but I don't think there's much to summarize; see
below.

> How synched is it to actual developments in which branch?

I think no one synchs it.  But the patch is quite localized, so it
shouldn't be hard to merge it with the current CVS HEAD.  At least I
hope so.

> I just got back from a conference where somebody doing critical
> editions of Arabic text said that pretty much the only usable editor
> (as in: renders characters correctly) for Unicode R-to-L was Unipad
> under Windows.

Yes, it's very sad, especially since the core reordering code was
written 5 and a half years ago.  (However, I think there's also Yudit,
http://www.yudit.org/.)

> Do people actually use emacs-bidi nowadays?

I cannot imagine that someone uses it, since it crashes the moment you
turn on the bidi display option, even if the buffer consists of strict
left-to-right characters (e.g., ASCII).  The bidi display engine needs
work before it becomes even marginally usable.  Unfortunately, I don't
have anywhere near the time needed for this kind of job.  I can help
with advice and explanations about the code, though.

The reordering code was extensively tested wrapped in a stand-alone
program, so I expect most of the debugging needs to take care of the
way Emacs calls the buffer iterator and moves around the locus of the
iteration.  The testing I did emulated linear iteration through buffer
text, which is probably somewhat simpler than what Emacs actually does
when it prepares the next redisplay.

> Does it work for writing?  Just for Hebrew, or other R-to-L scripts,
> too?

It is supposed to work for all scripts that need bidirectional
display, provided that the directionality properties of the characters
are set up properly, which should already be so in Emacs 23, because
the properties are loaded from the Unicode character database.

The same code could be used, with a slightly different API, to produce
printed matter from bidirectional text.  I thought about both of these
applications during design and implementation of the reordering code.

> What about crazy things like T-to-B scripts (some Japanese and/or
> Chinese variants IIRC)?

The bidi reordering code I wrote doesn't support that.  It only
supports the functionality described in the Unicode Annex 9
(a.k.a. UAX #9).

> I'd be willing to try creating a Yiddish input encoding, though I'd
> probably have to think quite a bit of how to encode the various
> letters used in Hebrew words.  I don't think there is a standard
> unambiguous transliteration scheme for those around.

I don't understand: Yiddish uses Hebrew letters, and is written right
to left, like Hebrew.  So why do you need a new encoding and a new
input method?  You can just use the Hebrew input method (and hit the
same bidi non-support problem ;-).

What am I missing?