emacs-devel
[Top][All Lists]
Advanced

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

Re: bidi-display-reordering is now non-nil by default


From: Eli Zaretskii
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Mon, 15 Aug 2011 20:12:56 +0300

> From: David Kastrup <address@hidden>
> Date: Mon, 15 Aug 2011 16:18:14 +0200
> 
> If "format" creates a pure L2R string, it will not insert directional
> marks.

What is a "pure L2R string", for this purpose?  Is this a string that
does not get reordered for display, or a string that does not affect
strings concatenated with it?  Or something else?  I think this should
be carefully defined to make sense in this context; each of the above
alternatives could yield a different result for the same string.

> When it puts stuff together that would make cause changes of
> directionality from inside a field to outside, it would insert marks to
> avoid this.  So format("%sx", v) would not be equivalent to concat(v,
> "x").  Something like format("%\\sx", v) might: one would try to make
> some modifier for "don't insert directional marks".

This might work (although is non-trivial to code), but it requires
that the following string(s) be known to `format'.  Note: not just the
single following substring, but as much text as is needed to determine
whether a simple concatenation will or will not work.  For example, if
"x" in the above example is a string made of weak or neutral
characters (e.g., digits or punctuation or whitespace), `format' will
be unable to DTRT, unless we accept the sub-optimal solution of
inserting directional controls in this case anyway.

Of course, it also means relevant Lisp code will have to be modified
to not use `concat' or `insert' to generate text out of its fragments,
but instead to use these special features of `format'.

> But if the point is to get behavior that is rather close to optimal
> without regressions for L2R texts

This "rather close to optimal" goal should also be clearly defined,
IMO.



reply via email to

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