Re: RLM and LRM are composed?

[Kenichi Handa <handa@m17n.org>]

In article <83eiizy5bg.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > But, the detection of non-spacing mark is done by
> > (= (aref char-width-table CH) 0).

> Hmm.. and why is this wrong?

All formatting characters has width 0 but they are not
combining characters that Unicode expect to be combined with
a preceding base character.

> Anyway, (aref char-width-table #x200f) => 0, so it sounds like the
> current detection should have worked.  What am I missing?

The situation is a little bit complicated.  For U+200F, we
set this list in the composition-function-table.

(["\\c.\\c^+" 1 compose-gstring-for-graphic]
 [nil 0 compose-gstring-for-graphic])

This should read as follows (provided that the buffer
position of U+200F is POS).

(cond
 ((save-excursion (goto-char (1- POS)) (looking-at "\\c.\\c^+"))
  (compose-gstring-for-graphic
   (composition-get-gstring (1- POS) (mathc-end 0) ...)))
 (t (compose-gstring-for-graphic
     (composition-get-gstring POS (1+ POS) ...))))

Here as U+200F doesn't has category "^" (combining), the
second condition succeeds, and compose-gstring-for-graphic
tries to compose just one char U+200F.  The problem here is
that the original intention of the second condition is for
an independent combining character not following a base
character, not for a non-combining character of zero width.

What compose-gstring-for-graphic does for a single character
is to adjust the metrics of the glyph to display it as if it
is a spacing character so that a user can edit that
character easily.

Please give me more time to consider the detail of the
current situation.

For your 2nd question:

> 2. Is it a bug or a feature that composed characters don't go through
>    the display table?  If it's a feature, what is its purpose?

perhaps we should apply the display table at least to a
character that is composed only by itself (i.e. one-char
composition as in the above case).

---
Kenichi Handa
handa@m17n.org