Hello Eli, Amit,
On 2010/07/01 2:55, Eli Zaretskii wrote:
Date: Wed, 30 Jun 2010 02:04:30 +0300
From: Amit Aronovitch<[email protected]>
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:[email protected]
_______________________________________________
emacs-bidi mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-bidi
