Re: [emacs-bidi] status? news?

[Eli Zaretskii]

> Date: Sun, 21 Jan 2001 17:37:21 +0330 (IRT)
> From: Roozbeh Pournader <address@hidden>
> 
> With implicit bidi support (with LRM and RLM, but without LRE, RLE,
> LRO, RLO, and PDF), you can first break the lines, and then apply bidi to
> each line separately for reordering before the display.
> 
> With explicit support, you should first do bidi on the whole paragraph,
> then break the lines, and finally reorder the text.

I think there are several implicit assumptions here, without which the
above problems don't exist.

The first assumption is that logical-to-visual transformation is done
on large blocks of text---lines or paragraphs.

The second assumption is that the code which breaks the lines works on
the logical buffer contents.

[For the purposes of this discussion, I assume that what you call
``breaking lines'' is what Emacs calls ``continuation lines'', whereby
a suitable glyph, like `\' on character terminals, is displayed at the
window's margin, and the rest of the line occupies successive display
lines.]

Neither of the above assumptions is true for Emacs.  The second
assumption is wrong because the decision where to break the line is
made as part of the basic display engine code, which examines buffer
text one character at a time and makes such decision as it goes.  This
is so in current display code, and was so in previous versions of
Emacs as well.

The first assumption also doesn't hold, because the conversion between
logical and visual order will probably happen one character at a time
as well, since this fits well into the overall structure of Emacs
redisplay code.  That is, where the current display engine advances
through the buffer in the order of increasing buffer positions, in the
bidi case it will request and receive the _visually_ next character.
The workhorse of this will be a function that, given a buffer position
and some additional info, will advance to another buffer position
occupied by the visually-next character.  (At least this is the design
principle which I'm currently evaluating.)

Given this design, I think that the problem with breaking lines in the
presence of explicit embedding controls should not exist.

> > HTML has additional bidi directives, which I imagine are easier to 
> > support than the Unicode controls.  So HTML is probably in less trouble 
> > than plain text.
> 
> HTML needs the same treatment.

Yes, but it doesn't need to support the Unicode LRE, LRO,
etc. characters directly, since their use is discouraged.