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

[Eli Zaretskii <eliz@gnu.org>]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: monnier@iro.umontreal.ca, dak@gnu.org, emacs-devel@gnu.org
> Date: Tue, 16 Aug 2011 11:48:54 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> since there is no near-term solution, how bout turning off bidi
> >> display reordering for prog-mode buffers?
> >
> > What for?  No one complained about it yet
> 
> I think I mentioned in an earlier message that the presence of RTL
> characters mucks up the display of Emacs Lisp buffers.  This happend to
> me while writing code containing RTL strings to test
> string-mark-left-to-right.

Won't a newline and/or LRM/RLM (the latter inside the string) fix
that?  If not, please show me the relevant examples.

In general, all reordering information is tossed at every newline and
restarted anew for the next line.  So judicious placement of newlines
should do the trick in most cases.

> Those buffers aren't displayed in an intelligible manner, because
> they require missing "higher-level protocols" to display properly.

I think you exaggerate.  Both strings and comments are mostly
displayed correctly, and a few nasty surprises can be fixed by
inserting newlines and sometimes directional control characters.
Sure, there's place for improvement: Emacs should not force the user
to format the source in some specific manner, for it to display
correctly.  But for someone who actually uses R2L characters in
comments and strings, this is a definite improvement compared to Emacs
23, where they had to read them backwards.

> In prog modes, which require that higher-level segmentation
> functionality, it then makes sense to disable bidi display for now.

I disagree (see above), but I'll go with anything you and Stefan
decide.

> This would also give a lot more time to study different ways of
> implementing segmentation (e.g. definining segmentation characters vs
> extending the bidi code to recognize text properties).

I don't think we should feel pressed to resolve this before Emacs
24.1, since the problem is not as acute as it may seem at first
glance.  So we have that time anyway.