Re: [emacs-bidi] Suboptimal display-reordering in minibuffer

[Martin J. Dürst]

Hello Eli,

On 2010/07/01 12:14, Eli Zaretskii wrote:

> You are suggesting to insert bidirectional format characters into the
> buffer text in order to affect the display.  That's a no-no, IMO:

I agree that that's a no-no, for the reasons you give below. But that's 
not what I was suggesting or thinking about. What I was suggesting 
(actually, the idea is originally from Kenichi Handa and/or Naoto 
Takahashi) is that these bidirectional formatting characters go into the 
text only 'virtually', e.g. in the before-string or after-string 
properties of an overlay (see 
http://www.gnu.org/software/emacs/elisp/html_node/Overlay-Properties.html#Overlay-Properties). 
In that way, In my understanding, they are not part of the text buffer, 
and will not be saved when saving the file.

Of course, if the characters in the overlay properties before-string and 
after-string are not currently taken into account when running the bidi 
algorithm, then that approach may not work very easily.

In any way, I think it's better to use the concepts already available in 
the Unicode Bidi algorithm (override, embedding, marks) for improving 
the display of XML, HTML, and other structured data and program source, 
rather than to invent completely new concepts. Whether these concepts 
then get transferred to the bidi algorithm via the (faked) insertion of 
characters or via some other way (one could imagine to have properties 
such as LRO/RLO/LRE/RLE on overlays,...) may be a secondary issue.

There are in my view two reasons for why it is better to reuse the concepts:
1) it is easier for "application-level" emacs-lisp programmers who work 
on updating modes to improve bidi display.
2) it is easier for the core implementer(s), i.e. you, because they have 
to work with only one algorithm.

Regards,    Martin.

> Emacs should not modify buffer text for display purposes.  If we do
> what you propose, we will open a can of worms, whereby bugs or crashes
> will cause Emacs to produce a file that is different from input, even
> if you didn't edit the file at all.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:address@hidden