bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#9571: 24.0.50; user option to turn off bidi, please


From: Eli Zaretskii
Subject: bug#9571: 24.0.50; user option to turn off bidi, please
Date: Sat, 24 Sep 2011 17:04:11 +0300

> Date: Sat, 24 Sep 2011 08:28:20 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: drew.adams@oracle.com, 9571@debbugs.gnu.org
> 
> Those messages seem to be arguing against maintaining big changes to
> implement non-bidi display.  I agree with that.
> 
> But they don't seem to be an argument against simple code that would
> disable the recognition of the bidi specialness of characters.

That's an entirely different request, it was never voiced before (and
I suspect that it won't satisfy people who argue for a user option to
disable reordering).  Assuming I understand the request correctly, see
below.

The way I understand this request is: make it so that the result of
reordering is the text in its original logical (i.e. buffer or string)
order.  The code that is involved in reordering, largely in bidi.c and
xdisp.c, will still work as it normally does.

Is this what you are asking for?  If so, then the way to have this is
to modify the relevant Unicode property of the R2L characters so that
they are treated as L2R.  This is easier in Lisp than in C, because
the table where these properties are kept is just a specialized form
of a char-table, and Lisp code can modify it.

Note that we currently have no mechanism for making this table of
Unicode properties buffer-local, so changing the properties will
affect all the windows on all the frames.  But since we are talking
about something that's supposed to be used for very short periods of
time for exploring rare problems, I think it's not too important.

If it's important, and Stefan and Chong agree, I can write a command
to do this.

Again, I don't think this is what the original proponents of the
option wanted, because implementing what you suggest will not bypass
any of the code in the new display.  IOW, I think it's an entirely
different feature.





reply via email to

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