From: Kenichi Handa <handa@m17n.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: yair.f.lists@gmail.com, emacs-devel@gnu.org, jasonr@gnu.org
Subject: Re: Composing Hebrew diacriticals
Date: Fri, 14 May 2010 20:58:00 +0900 [thread overview]
Message-ID: <tl7ljbmbsqf.fsf@m17n.org> (raw)
In-Reply-To: <837hn64x96.fsf@gnu.org> (message from Eli Zaretskii on Fri, 14 May 2010 13:02:13 +0300)
In article <837hn64x96.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> 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
handa@m17n.org
next prev parent reply other threads:[~2010-05-14 11:58 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-30 12:29 Composing Hebrew diacriticals Eli Zaretskii
2010-05-05 2:39 ` Kenichi Handa
2010-05-05 15:49 ` David Kastrup
2010-05-05 20:51 ` Eli Zaretskii
2010-05-06 7:20 ` David Kastrup
2010-05-06 0:45 ` Kenichi Handa
2010-05-06 12:14 ` David Kastrup
2010-05-06 13:01 ` Kenichi Handa
2010-05-05 18:01 ` Eli Zaretskii
2010-05-07 11:15 ` Kenichi Handa
2010-05-08 12:51 ` Eli Zaretskii
2010-05-06 14:59 ` Yair F.
2010-05-06 17:41 ` Eli Zaretskii
2010-05-07 0:48 ` Kenichi Handa
2010-05-07 4:41 ` Yair F
2010-05-07 6:23 ` Kenichi Handa
2010-05-07 10:00 ` Yair F
2010-05-07 11:11 ` Kenichi Handa
2010-05-07 9:28 ` Eli Zaretskii
2010-05-10 14:09 ` Yair F
2010-05-11 0:25 ` Kenichi Handa
2010-05-11 12:20 ` Kenichi Handa
2010-05-11 16:22 ` Eli Zaretskii
2010-05-12 8:04 ` Kenichi Handa
2010-05-12 17:35 ` Eli Zaretskii
2010-05-12 19:05 ` Juanma Barranquero
2010-05-13 3:06 ` Eli Zaretskii
2010-05-13 0:42 ` Kenichi Handa
2010-05-14 8:10 ` Kenichi Handa
2010-05-14 10:02 ` Eli Zaretskii
2010-05-14 11:58 ` Kenichi Handa [this message]
2010-05-14 13:29 ` Eli Zaretskii
2010-05-14 14:06 ` Eli Zaretskii
[not found] ` <AANLkTilcNB_ntRY_EVS9EyMrqS3GRAp3rHGiXL_3YZuR@mail.gmail.com>
2010-05-15 2:14 ` Kenichi Handa
2010-05-15 21:35 ` Yair F
2010-05-17 4:35 ` Kenichi Handa
2010-05-17 17:32 ` Eli Zaretskii
2010-05-18 0:36 ` Kenichi Handa
2010-05-17 21:08 ` Yair F
2010-05-20 2:09 ` Kenichi Handa
2010-05-25 1:45 ` Kenichi Handa
2010-05-25 20:56 ` Yair F
2010-05-26 0:36 ` Kenichi Handa
2010-05-26 4:37 ` Yair F
2010-05-26 6:00 ` Kenichi Handa
2010-05-26 16:12 ` Yair F
2010-05-27 7:27 ` Kenichi Handa
2010-05-27 21:59 ` Yair F
2010-05-28 0:42 ` Kenichi Handa
2010-06-01 8:58 ` Yair F
2010-05-26 13:28 ` Enabling bidi (was: Composing Hebrew diacriticals) Stefan Monnier
2010-05-26 17:14 ` Eli Zaretskii
2010-05-27 4:13 ` Enabling bidi Stefan Monnier
2010-05-27 17:43 ` Eli Zaretskii
2010-05-18 7:29 ` Composing Hebrew diacriticals Eli Zaretskii
2010-05-17 13:53 ` Stefan Monnier
2010-05-19 17:23 ` Eli Zaretskii
2010-05-11 21:40 ` Yair F
2010-05-12 3:15 ` Eli Zaretskii
2010-05-12 15:11 ` Yair F
2010-05-12 17:43 ` Eli Zaretskii
2010-05-12 22:01 ` Yair F
2010-05-13 17:14 ` Eli Zaretskii
2010-05-13 19:46 ` Yair F
2010-05-13 19:56 ` Eli Zaretskii
2010-05-13 20:08 ` Yair F
2010-05-14 2:35 ` Miles Bader
2010-05-14 10:45 ` Yair F
2010-05-14 13:05 ` Eli Zaretskii
2010-05-14 13:15 ` Kenichi Handa
2010-05-15 0:46 ` Miles Bader
2010-05-13 0:29 ` Kenichi Handa
[not found] <tl7fx0v9nra.fsf@m17n.org>
2010-06-15 11:02 ` Kenichi Handa
2010-06-24 6:33 ` Kenichi Handa
2010-06-25 10:16 ` Eli Zaretskii
2010-06-28 16:40 ` Yair F
2010-06-29 8:07 ` Kenichi Handa
2010-06-29 18:57 ` Yair F
2010-06-30 5:27 ` Kenichi Handa
[not found] ` <AANLkTim3sQzyJ4YQkOzfRHCFhztgLG-CA2vlM84lbwoq@mail.gmail.com>
2010-06-30 21:48 ` Fwd: " Yair F
2010-07-01 5:59 ` Miles Bader
2010-07-01 5:52 ` Kenichi Handa
2010-07-01 20:30 ` Yair F
2010-07-02 7:51 ` Kenichi Handa
2010-07-12 8:17 ` Kenichi Handa
2010-07-12 21:10 ` Yair F
2010-07-13 4:11 ` Kenichi Handa
2010-07-13 4:47 ` Yair F
2010-07-13 12:01 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tl7ljbmbsqf.fsf@m17n.org \
--to=handa@m17n.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jasonr@gnu.org \
--cc=yair.f.lists@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.