Re: Composing Hebrew diacriticals

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> > Eli, please check the comments of set_iterator_to_next, and
> > verify that I'm doing the right thing.

> It looks okay at a first glance, thank you!

> In the HELLO buffer, the RLM character is not composed with the
> following parenthesis, though.  Is this a separate problem?

Currently Emacs' category of RLM (U+200F) is not '^'
(Combining).  So it is not composed with the previous base
character.

BTW, I don't know which is better; showing RLM (and the
other control characters) to users or not.  If we show it,
the display is a little bit annoying.  If we hide it, it
gets very difficult for users to manually edit it.

> I will work on the issues you raised in the comments.  For now, I have
> just one response: in this fragment from set_iterator_to_next:

>               /* Update IT's char/byte positions to point the first
>                  character of the next grapheme cluster, or to the
>                  character visually after the current composition.  */
>   #if 0
>               /* Is it ok to do this directly? */
>               IT_CHARPOS (*it) += it->cmp_it.nchars;
>               IT_BYTEPOS (*it) += it->cmp_it.nbytes;
>   #else
>               /* Or do we have to call bidi_get_next_char_visually
>                  repeatedly (perhaps not to confuse some internal
>                  state of bidi_it)?  At least we must do this if we
>                  have consumed all grapheme clusters in the current
>                  composition because the next character will be in the
>                  different bidi level.  */
>               for (i = 0; i < it->cmp_it.nchars; i++)
>                 bidi_get_next_char_visually (&it->bidi_it);

> the "#else" part is doing TRT.  You cannot jump to a different place
> in the buffer/string behind the back of bidi_get_next_char_visually,
> because that would violate the integrity of its internal cache, which
> must correspond to the buffer/string positions 1:1.

Ok, I see.

> > I have not yet committed proper codes for Hebrew
> > composition.  I'm now testing with this simple version.
> > 
> > (let ((pattern "[\u05D0-\u05F2][\u0591-\u05BF\u05C1-\u05C5\u05C7]+"))
> >   (set-char-table-range
> >    composition-function-table '(#x591 . #x5C7)
> >    (list (vector pattern 1 'font-shape-gstring)
> >      ["[\u0591-\u05C7]" 0 font-shape-gstring]))
> >   (set-char-table-range
> >    composition-function-table #x5C0 nil)
> >   (set-char-table-range
> >    composition-function-table #x5C6 nil))

> Could you please look at the message I posted in
> http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00251.html?
> I still see the infloop, with the current trunk, even when
> bidi-display-reordering is set to nil, after I type BET and DAGESH, as
> described in that message.  What kind of problems in the information
> that Uniscribe returns to Emacs could cause such a loop?

I'm now investigating that problem.

But, as I don't have Emacs on Windows now, all I can do is
just guessing.

To debug C code of Emacs on Windows, which environment
(cygwin, mingw, ...) is good?  It will be good that there's
an instruction simply showing just one method by saying
something like:

(1) Download this and this and this...  (with actual URLs).
(2) Install this, then do this, then install this, then do this...
(3) Build Emacs under this terminal program.

---
Kenichi Handa
address@hidden