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

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <address@hidden>
> Date: Wed, 03 Aug 2011 20:45:16 +0200
> Cc: address@hidden
> 
> Mohsen BANAN <address@hidden> writes:
> 
> > The low hanging fruit right now is:
> >
> >   1) Adding an LRM character after the subject
> >      line in the Suummary buffer.
> >
> >   2) Adding an LRM character after the From name
> >      in the Summary buffer.
> 
> As I said earlier, I think adding characters to the text to control pure
> layout issues is a sub-optimal design decision.

You are wrong.  LRM, RLM, etc. exist _precisely_ for these purposes:
to arrange bidirectional text for display as the display designer
wishes, where the implicit reordering mandated by the UBA does not
give satisfactory results.  These _explicit_ directional control
characters exist for when the _implicit_ reordering fails.  It's the
functional equivalent of the corresponding HTML directives -- you
won't say that HTML is "suboptimal" when it dictates to the browser
how to render bidirectional text, would you?

> Why not control this stuff with text properties, like we do with
> (almost) anything else that's similar to this?

Because (a) text properties are specific to Emacs, and (b) they cannot
overlap (for the same property).  By contrast, to force certain visual
order, one must sometimes force some direction on a portion of text
and then the opposite direction on an inner substring of that very
text.  Text properties won't grok that.

This issue was discussed at length long ago, when the basic design of
bidi support for Emacs was on the table.  Text properties were
suggested almost immediately, then rejected after prolonged debates,
because they simply aren't up to this job, and because the Unicode
Standard already tells us how to DTRT, we just need to heed.

> LRM characters seem like a neat hack for things like the HELLO file,
> where you have a plain text file.  But for stuff like the summary
> buffer, you're basically just concerned with lining stuff up properly.
> Adding special characters here doesn't seem warranted to me.

What is the difference between aligning HELLO and aligning a summary
buffer?  They are both plain text, and they both are arranged to align
nicely.

> And for those who forgot the two options we have with LRM:
> 
> 1) make the LRM invisible and intangible, which means that if somebody
> cuts and pastes a (seemingly) ASCII summary buffer, it'll be
> (inexplicably) utf-8 with LRM characters interspersed after saving or
> mailing it, or
> 
> 2) have the LRM characters visible, which means that pushing <Right>
> over a line will have an inexplicable "stop" several times over the
> line.

The latter is not true: a visible LRM displays as a thin space, so the
cursor is not stuck.

> Please correct me if this isn't what all y'all have in mind.

Using LRM/RLM _is_ TRT, Lars.  It may sound weird to you, but it's
like democracy: the worst political system, except all the rest.  I
wrote the entire Hebrew tutorial with these characters, and didn't see
any problems.  It just takes some time to get used to it, that's all.
R2L users already are used to it.