bug#3452: 23.0.94; display

[Kenichi Handa <handa@m17n.org>]

In article <877hzoogc1.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> > The problem stems from the character 8237 (#o20055, #x202d),
> > LEFT-TO-RIGHT OVERRIDE.  For some reason, the composition for this
> > character screws up line wrapping.

> Hi Handa-san, I investigated some more.  Let me know what you think.

> The entry for 8237 (#x202d) in char-width-table is 0: that is to say,
> char-width-table reports that the composition has zero width.  This is
> because of the following code in characters.el:

>   (let ((l '((#x0300 . #x036F)
>             ...
>             (#x202A . #x202E)
>             (#xE0001 . #xE01EF))))
>     (dolist (elt l)
>       (set-char-table-range char-width-table elt 0)))

> The function fill_gstring_body in composite.c uses char-width-table.
> However, composition_gstring_width for this character, called in
> term.c:1830, returns 1.  This inconsistency leads to the bug.

There's no inconsistency.

On terminal, if a zero-width character doesn't follow a base
character, Emacs composes that character by prepending SPACE
hoping that the terminal treats that zero-width character as
zero-width too.  This is to make that character still
edittable (e.g. we can put cursor on it) in Emacs.

So, even if char-width-table says it's zero width, all Emacs
display routines including indent.c treat that character's
width as 1.

But, gnome-terminal doesn't treat that character as
zero-width.  Please make the file "temp" by this code:

(with-temp-file "~/temp" (insert #x202d ?a ?\n))

and do "% cat ~/temp" on gnome-terminal.

> Maybe we should reconsider setting these characters to have zero-width
> for char-width-table in characters.el, since fill-gstring-body seems to
> handle zero-width compositions poorly.  WDYT?

fill_gstring_body (in composite.c) just initializes gstring.
The actual composition function
(compose-gstring-for-terminal on terminal) does the above
composition.

In article <E1MDEU1-0004sV-3H@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> I think it would be a bad idea to set these characters to anything but
> zero width.

I agree with that.

> These characters are not supposed to be displayed at all,
> they have no meaningful glyphs to show them.  They are just directives
> to the bidirectional display engines about how to convert logical
> order of characters to visual order.

But as Emacs 23 doesn't support bidi, at least we should
make it edittable, don't we?

> Btw, I don't understand how these characters are related to
> compositions.  They should not be composed with anything, they always
> stand for themselves.

Currently they are not composed with any other surrounding
characters (but only with an artificially prepended SPACE),
so we can say that they stand for themselves.

To conclude, I think there's not that much we can do for
this situation.  I think the current behaviour of
gnome-terminal (displaying standalone U+202D as a space of
width 1) is a bug.

---
Kenichi Handa
handa@m17n.org