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

[Martin J. Dürst]

Hello Eli, Amit,


On 2010/07/01 2:55, Eli Zaretskii wrote:
> > Date: Wed, 30 Jun 2010 02:04:30 +0300
> > From: Amit Aronovitch<address@hidden>

> > > The important thing is to establish whether we need some
> > > infrastructure in Emacs that is currently missing, because that would
> > > need to be coded first, before any user-visible progress can be made.
> >
> > I believe that the required infrastructure has a lot in common with the
> > coloring (font-lock) system.
>
> It's not that simple.  The way bidi reordering is designed and
> implemented in Emacs, the reordering itself happens _before_ faces,
> overlays, and other display features are considered.  The bidi
> reordering engine is totally oblivious to text properties, overlays,
> images, etc.; it just controls which character will be considered next
> for delivering it to the display, and all the rest, i.e. calculation
> of the face of that character, its display metrics, etc. -- all this
> happens _after_ reordering, in code that calls the reordering engine.

I think what Amit meant is that there is quite some similarity between 
the code that analyzes e.g. a C file to find out which parts are string 
constants,... for coloring and the code that we will need to find parts 
such as string constants,... for improved bidi display. I fully agree 
with this. Ideally, the additional emacs-lisp code that we will need for 
the various modes for each programming language or format will be just 
minor additions to what's already there for syntax coloring,...

That should not be in conflict with the actual implementation of bidi, 
coloring,... in the display engine, which happens at a quite different 
level, and in a different order, as described above by Eli.


> What we need is a way of telling the reordering engine to reorder only
> portions of buffer text.  This is the infrastructure I was thinking
> about, because I don't think we have anything like that at this time.
> And I'm not sure it is a good idea to base the implementation on text
> properties or overlays, at least not text properties of the kind used
> for fontification.

Please note that we already have a way for telling the reordering engine 
to "reorder only portions of buffer text", or alternatively, to "reorder 
portions of buffer text differently", in the Unicode Bidi algorithm. 
It's called Overrides and Embeddings. According to our experience 
implementing better display for HTML and XML in HTML, being able to add 
Overrides and Embeddings (and RLM/LRM marks) in a way that does not 
affect the actual text in a buffer (e.g. as it would be stored to a 
file) should be sufficient for getting the job done. I think we should 
first explore this path and only if it fails should we start to create 
additional infrastructure.

Regards,    Martin.

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