[Top][All Lists]

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

Re: Composing Hebrew diacriticals

From: Kenichi Handa
Subject: Re: Composing Hebrew diacriticals
Date: Fri, 14 May 2010 20:58:00 +0900

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

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

reply via email to

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