bug#3452: 23.0.94; display

[Eli Zaretskii <eliz@gnu.org>]

> From: Kenichi Handa <handa@m17n.org>
> Date: Mon, 08 Jun 2009 10:51:14 +0900
> Cc: 3452@emacsbugs.donarmstrong.com
> Reply-To: Kenichi Handa <handa@m17n.org>, 3452@emacsbugs.donarmstrong.com
> 
> 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.

So these characters should be currently displayed as SPACE?

Is it a good idea to rely on the terminal in this situation?  Do we
know for a fact that many (most?) terminals indeed behave like that
with zero-width characters?

> > 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?

Yes, definitely.  (Btw, I think make them editable even when Emacs
does support bidirectional editing.)

> > 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.

That's good, I think.

> 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.

If other terminals behave correctly, I would agree.  But if not,
perhaps we need to work around this, if possible.  For example, we
could have an entry in display tables for these characters.