[Top][All Lists]

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

Re: [emacs-bidi] Mixed L2R and R2L paragraphs and horizontal scroll

From: Eli Zaretskii
Subject: Re: [emacs-bidi] Mixed L2R and R2L paragraphs and horizontal scroll
Date: Fri, 12 Feb 2010 14:36:39 +0200

> Date: Fri, 12 Feb 2010 13:03:52 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> > So if only the line breaking points were static, you'd have no
> > performance problem!
> If the line breaking points were at known buffer positions, yes.

Actually, that's not true, in general.  Embeddings break that.

Here's an example.  Imagine the following text in logical order:

  he said "I HEARD HIM SAYING ['car is CAR in arabic'] AND FAINTED"

The [...] part is an embedding: it is there to have this text display

  he said "DETNIAF DNA 'car is RAC in arabic' GNIYAS MIH DRAEH I"

rather than as

  he said "GNIYAS MIH DRAEH I 'car is RAC in arabic' DETNIAF DNA"

The latter display does not express what the writer of the text wanted
to say.  (Please don't nit-pick wrt the known issues with reordering
quotes and apostrophes: they are here just to make the text more
readable, and can be easily removed without affecting the fundamental
problem I'm talking about.)  UAX#9 allows up to 60 levels of such
embeddings, btw.  The characters [ and ] represent special Unicode
code points known as LRE and PDF, respectively.  There are also LRO,
RLE, and RLO, for similar jobs but with the other direction.

Now, suppose the window is only wide enough to display this:

  he said "'car is GNIYAS MIH DRAEH I"

The continuation line should then display the rest of the text:

  "DETNIAF DNA RAC in arabic'

(again, disregard the placement of quotes).  Right?  Or does this look
incorrect?  If so, what is the correct display in this case?

Anyway, if we stop the bidi reordering after "car is", and restart it
at "CAR", the information about the unfinished embedding is lost, and
the continuation line will be displayed differently.

Which means breaking the line in the middle of an embedding is tricky
at best.  It also means that putting a newline on some whitespace
character, like fill-paragraph does, will have the same problem of
generating incorrect (or at least unexpected) display of the second
part of the broken line.

Conclusion: to apply such smart line continuation, we need first to
establish where are the points at which we are allowed to break the

reply via email to

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