|
From: | Martin J. Dürst |
Subject: | Re: [emacs-bidi] Suboptimal display-reordering in minibuffer |
Date: | Thu, 01 Jul 2010 10:50:30 +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, 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
[Prev in Thread] | Current Thread | [Next in Thread] |