[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [emacs-bidi] Suboptimal display-reordering in minibuffer
From: |
Martin J. Dürst |
Subject: |
Re: [emacs-bidi] Suboptimal display-reordering in minibuffer |
Date: |
Thu, 01 Jul 2010 15:37:35 +0900 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 |
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
- Re: [emacs-bidi] Suboptimal display-reordering in minibuffer,
Martin J. Dürst <=
- Re: [emacs-bidi] Suboptimal display-reordering in minibuffer, Eli Zaretskii, 2010/07/01
- Re: [emacs-bidi] Suboptimal display-reordering in minibuffer, Martin J. Dürst, 2010/07/01
- [emacs-bidi] Supporting non-plain-text buffers (was: Suboptimal display-reordering in minibuffer), Eli Zaretskii, 2010/07/02
- [emacs-bidi] Re: Supporting non-plain-text buffers, Martin J. Dürst, 2010/07/06
- [emacs-bidi] Re: Supporting non-plain-text buffers, Eli Zaretskii, 2010/07/07
- [emacs-bidi] Re: Supporting non-plain-text buffers, Martin J. Dürst, 2010/07/15
- [emacs-bidi] Re: Supporting non-plain-text buffers, Eli Zaretskii, 2010/07/15
Re: [emacs-bidi] Suboptimal display-reordering in minibuffer, Beni Cherniavsky-Paskin, 2010/07/02