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

[Eli Zaretskii]

> Date: Fri, 5 Feb 2010 14:21:49 +0200
> From: "Ehud Karni" <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> On Thu, 04 Feb 2010 21:40:32 Eli Zaretskii wrote:
> >
> > Please!  Newspapers don't have truncated and continued lines, they
> > have newlines between every two lines.  With newlines, the bidi
> > display will show exactly what you (and every other Hebrew reader)
> > expect.
> 
> I think you got it wrong here. Newspaper article are written a whole
> paragraph without new lines on a wide screen and then reflowed to
> the column width. You can do it with any word processor, and change
> the width when you print and get the same behavior.

Emacs's way of re-flowing is by inserting newlines.  Continuation
lines are not it, because they break the line in an arbitrary place,
like the middle of a word.  This is a no-no in any newspaper article.

> I propose the following: use a virtual "right-margin-goal-column" (a
> real one if given, and if not it is the screen width), do a virtual
> `fill-paragraph' on the line, and do the bidi processing on the
> result, BUT without inserting any real new-lines.

I explained elsewhere why this does not solve the problem: the
reordering code works below the glyph layout code, so it has no idea
when it has reached the right-margin-goal-column.  At least I don't
know how to do that; ideas are welcome.

The reordering code can do what you want if we somehow tell it at
which _buffer_position_ to stop, as if it hits a newline or a
paragraph separator.  But buffer positions are not equivalent to
display positions, due to display features like:

  . variable fonts and faces
  . glyphs that come from overlays, `display' properties, images, etc.
  . `wrap-prefix' and `line-prefix' variables
  . composite characters
  . tab expansion

(probably forgot a few).  Note that the last one affects text
terminals as well, so even there you cannot simply count characters.

> It has the shortcoming of not going exactly up to right edge (or left
> edge for R2L paragraph), but it will have the benefit of not breaking
> words and allowing normal reading for long line with embedding text of
> the opposite direction.

The problem is that, for the reasons I explain above and in a previous
message in this thread, what you suggest will still end up overflowing
the margin sometimes, and we are back with the same problem.  (If I
understood your suggestion, that is; if not, please point out where
I'm wrong.)