From: Eli Zaretskii <eliz@gnu.org>
To: Kenichi Handa <handa@m17n.org>
Cc: emacs-devel@gnu.org
Subject: Re: Compositions and bidi display
Date: Mon, 26 Apr 2010 21:40:45 +0300 [thread overview]
Message-ID: <837hnuys42.fsf@gnu.org> (raw)
In-Reply-To: <tl78w8aih9t.fsf@m17n.org>
> From: Kenichi Handa <handa@m17n.org>
> Date: Mon, 26 Apr 2010 20:29:18 +0900
> Cc: emacs-devel@gnu.org
>
> All composition-related functions expect characters are in
> logical order.
I assumed that much. Sigh...
> So, the bidi reordering must happen after composition handling is
> done.
Unfortunately, this is impossible, not without throwing away the
entire design and current implementation of the bidi reordering, and
implementing it in a totally different way that will have to be much
more invasive into the overall design of Emacs display engine.
The reason is, as you know, that bidi reordering in Emacs is
conceptually just a replacement for advancing from one character to
the next during iteration through buffers or strings. Instead of
incrementing the character position to the next character, we modify
the position non-linearly to get to the next character in the visual
order. Obviously, this iteration is a lower-level operation than character
composition.
In addition, the bidi reordering engine knows nothing about the
characters it encounters except their bidirectional properties; in
particular, it doesn't know anything about character compositions, and
teaching it about them would mean rather serious complications.
Moreover, the bidirectional properties are in general defined for
individual characters, not for the composed ones, which is one more
reason it is very hard to do what you suggest, even if we would turn
the current design inside out. For example, we compose Hebrew
consonants with diacriticals into a single glyph, but that glyph has
no character codepoint to look up its bidirectional properties in the
Unicode database. So, once composed, these characters cannot be
reordered by following the UAX#9 algorithm without complications,
because UAX#9 is explicitly defined to work _before_ any shaping of
characters for display, see Section 3.5 there.
Therefore, I will need to find and handle sequences of characters to
be composed as an integral part of next_element_from_buffer, similarly
to what is already done with face changes there.
The idea is to detect the situation where the bidi iteration placed us
into a composable sequence of characters, and when that happens,
compose them and deliver them as a single display element, and then
skip the entire sequence, like we do today in the unidirectional
display. The tricky part is that today we only detect this when we
hit the beginning of such a sequence, while moving in the strictly
increasing order of buffer positions; with bidi reordering we will
need to detect them from the end of the sequence as well, for when the
bidi iterator moves backwards or jumps across many character
positions.
Is it possible to write a function or macro that will find out, for a
particular buffer/string position, whether that position is at the end
or in the middle of a composable sequence of characters, and if so,
return the character positions of the first and last characters of the
sequence? Something like CHAR_COMPOSED_P, but one that looks back in
the buffer? If so, could you please help me write such a function?
TIA
next prev parent reply other threads:[~2010-04-26 18:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 20:50 bug#5977: 24.0.50; Lao HELLO is incorrectly displayed Peter Dyballa
2010-04-19 23:15 ` Jason Rumney
2010-04-20 9:14 ` Eli Zaretskii
2010-04-20 23:16 ` Jason Rumney
2010-04-20 9:06 ` Eli Zaretskii
2010-04-20 10:28 ` Peter Dyballa
2010-04-20 12:17 ` Eli Zaretskii
2010-04-23 18:31 ` Eli Zaretskii
2010-04-21 2:32 ` Kenichi Handa
2010-04-23 18:52 ` Compositions and bidi display (was: bug#5977: 24.0.50; Lao HELLO is incorrectly displayed) Eli Zaretskii
2010-04-23 20:34 ` Andreas Schwab
2010-04-23 20:43 ` Eli Zaretskii
2010-04-24 11:27 ` Eli Zaretskii
2010-04-26 2:09 ` Kenichi Handa
2010-04-26 2:38 ` Kenichi Handa
2010-04-26 11:29 ` Kenichi Handa
2010-04-26 18:40 ` Eli Zaretskii [this message]
2010-04-27 12:15 ` Compositions and bidi display Kenichi Handa
2010-04-28 3:18 ` Eli Zaretskii
2010-04-28 4:01 ` Kenichi Handa
2010-04-28 17:38 ` Eli Zaretskii
2010-04-28 22:49 ` Stefan Monnier
2010-04-29 3:12 ` Eli Zaretskii
2010-04-30 2:28 ` Kenichi Handa
2010-04-30 6:41 ` Eli Zaretskii
2010-04-30 6:06 ` Kenichi Handa
2010-04-30 7:08 ` Eli Zaretskii
2010-05-03 2:39 ` Kenichi Handa
2010-05-03 7:31 ` Eli Zaretskii
2010-05-04 9:19 ` Kenichi Handa
2010-05-04 17:47 ` Eli Zaretskii
2010-04-30 10:07 ` Eli Zaretskii
2010-04-30 12:12 ` Kenichi Handa
2010-04-30 13:15 ` Eli Zaretskii
2010-04-27 3:13 ` Compositions and bidi display (was: bug#5977: 24.0.50; Lao HELLO is incorrectly displayed) Eli Zaretskii
2010-04-27 12:26 ` Kenichi Handa
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=837hnuys42.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=handa@m17n.org \
/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.