[Top][All Lists]

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

Re: bidi-display-reordering is now non-nil by default

From: Kenichi Handa
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Tue, 09 Aug 2011 15:11:41 +0900

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> >   Guidelines of [Unicode]). Paragraphs may also be
> >   determined by higher-level protocols: for example, the
> >   text in two different cells of a table will be in
> >   different paragraphs.
> > 
> > The case of summary line belongs to the last sentence above.

> That is one possible interpretation, yes.  But it isn't the only one.

I think it is the most natural/appropriate interpretation.

> The goal is to have correct display of the summary lines, not to
> decide whether we are dealing with cells or not.  Directional control
> character allow to render summary lines for display correctly even
> without "cells".

They can, but it is better to avoid using them to workaround
the "cell" problem.

> As for "artificial paragraph separators": I don't want to bother
> people with too many technicalities (interested readers can read
> relevant portions of bidi.c), but supporting "paragraphs" that have no
> relation to newlines, i.e. begin and end not on line boundaries, would
> mean a significant surgery of the current reordering engine.  So even
> if this is deemed as the optimal solution (and I'm not at all
> convinced it is), it won't make it in time for Emacs 24.1, at the very
> least.

> Actually, any solution based on special text properties has a similar
> problem: bidi.c works below handle_stop, and ignores text properties
> entirely (with the single exception of `display' properties that
> replace the underlying text with something else, like images or
> display strings).  So any such solution will also be out of the
> question for Emacs 24.1.

I think we should not stop finding the right solution just
to release 24.1 on time.  Isn't it worth delaying 24.1 for
the right solution?

Kenichi Handa

reply via email to

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