[Top][All Lists]

[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: Fri, 05 Aug 2011 09:56:50 +0300

> From: Michael Welsh Duggan <address@hidden>
> Cc: Lars Magne Ingebrigtsen <address@hidden>,  address@hidden,  address@hidden
> Date: Thu, 04 Aug 2011 23:41:27 -0400
> Scenario: Say we are desirous of updating XML mode to protect the
> neutral characters that make up tags so they don't end up in visually
> confusing locations.  This can be done by adding proper directional
> codes in the right locations.

I was not arguing for inserting directional control characters into a
buffer that visits a file.  If there are no such directional control
characters in the file, it is a very bad idea for Emacs to insert them
for display purposes: it will run a high risk of leaking those extra
characters back to the file.  Your questions all explain why this
would be a bad idea.

The current features of bidirectional display do not yet support
display of structured files, such as XML or comments and strings in
program files (the latter "mostly" works, but only by accident).
Supporting XML and similar structured text will need additional
features that are not yet there.  I don't even have a clear idea yet
of what such a features would be.  Sorry.

The only thing you can do with the current bidi support that should
work is to cover each string that may need reordering with a display
property whose value is that same string.  If you carefully exclude
from the string all the neutral characters that get in the way of the
"normal" reordering, you should get the effect that you expect.  (I
think; I didn't actually try that.)

The disadvantage of this is that _editing_ those strings will be
complicated: you will need to intercept cursor motion command and use
the `cursor' property a lot to let the user think the cursor can enter
such a string.  You will also need to recompute the display string
each time its origin in the buffer is modified.  That's tedious at
best, but at least it has a chance to work well with the current
infrastructure.  I think.

If you try this suggestion, and find it feasible, then perhaps it
could be a basis for solving this problem, or even a large part of
the solution.

reply via email to

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