[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bidirectional editing in Emacs -- main design decisions

From: Eli Zaretskii
Subject: Re: Bidirectional editing in Emacs -- main design decisions
Date: Mon, 18 Apr 2011 17:54:50 +0300

> Date: Fri, 09 Oct 2009 23:18:00 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: 
> While there's a lot of turf to be covered yet, I thought I'd publish
> the main design decisions up to this point.

I don't know if someone follows these design decisions, but in case
people are interested, here's an update:

> 6. Reordering of strings from `display' properties
>    ...
>    Another, perhaps more serious implication of this design decision
>    is that strings from `display' properties are reordered separately
>    from the surrounding buffer text.  IOW, production of glyphs from
>    reordered buffer text is stopped when a `display' property is
>    found, the string that is the property's value is reordered and
>    displayed, and then the rest of text is reordered and its glyphs
>    produced.

After careful thought, I changed my mind about this part.  Whenever
the redisplay iterator finds text that is covered by a `display' text
property or by an overlay with a `display', `before-string', or
`after-string' property, it will not stop reordering.  Instead, it
will treat the entire run of text covered by the text property or
overlay as a single atomic entity, and will reorder it as if it were a
single special character whose name in Unicode is OBJECT REPLACEMENT
CHARACTER (u+FFFC).  This character's bidirectional category (Other
Neutral) and other properties are designed so that it can stand for
display features such as embedded images, and in particular it is
reordered as appropriate for such embedded objects.

This will reorder images and display strings in the same way wrt
surrounding text, which I think is reasonable.  It is also in line
with the pre-Emacs 24 unidirectional display engine, which skipped the
text covered by such properties in one go, after displaying the image
or a display string specified by the property.

I hope this is the last "main design decision" regarding the basic
bidirectional display.  Barring any unexpected events, I will soon
begin implementing reordering of display strings and images, and what
will be left is "just" debugging.

What will remain in the design department after that is bidirectional
display in buffers that are not plain text: program source files
(where bidirectional scripts can be found in strings and comments) and
markup languages such as HTML and XML.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]