[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27544: 25.1; Visualization of Unicode bidirectional marks

From: Eli Zaretskii
Subject: bug#27544: 25.1; Visualization of Unicode bidirectional marks
Date: Sat, 01 Jul 2017 15:16:51 +0300

> From: Itai Berli <address@hidden>
> Date: Sat, 1 Jul 2017 14:48:21 +0300
> A default should be something that aligns with the expectations of a
> casual user; you cannot expect a casual user to start writing elisp
> code or tinkering with `glyphless-char-display-control`.
> And how can we know what a casual user would expect?

Thank you for describing your expectations.  However, to change the
defaults, we'd need to hear from more than one user.  If we find that
the majority thinks the default should be changed, we will eventually
do that, as we do with any other default.

> 1. We can follow established standards, particularly if we claim to
> conform to them, as Emacs does to the Unicode standard. The Unicode
> bidi algorithm 8.0.0 specifications state the following about LRM, RLM
> and ALM (section 2.6 Implicit Directional Marks):
> > they do not display or have any other semantic effect
> and again, in the same section:
> >  they do not appear in the display

The UBA also allows to retain these characters, including display
them, see section 5.2 there.  This is how Emacs behaves, again in line
with general Emacs feature of allowing users to see what's in the

> 4. We can see how Emacs implements similar constructs. The bidi marks
> are control sequences that can be inserted into the editor using `C-x
> 8 RET <Unicode hex number>`. Let's see how other control sequences are
> handled by this mechanism. If you try to insert, say, the characters
> Null character (U+0000), Bell character (U+0007) and Escape character
> (U+001B) using this method, we'll get:

There are control characters other than those which you tried, for
which Emacs does use the same display method as for bidi controls: try
ZWJ (U+200D) or ARABIC NUMBER SIGN (U+0600) -- all the characters of
Unicode General Category "Cf" that don't have an established graphic
image are by default displayed as thin spaces.  This is explained in
the doc string of glyphless-char-display-control.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]