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

[Eli Zaretskii]

> Date: Thu, 4 Feb 2010 16:02:58 +0200
> From: "Ehud Karni" <address@hidden>
> Cc: address@hidden, address@hidden
> 
> On Wed, 03 Feb 2010 20:59:13 Eli Zaretskii wrote:
> >
> > Maybe you are talking about how lines are re-flowed by these word
> > processors.  If so, the Emacs equivalent is fill-paragraph, or the
> > various packages (like longlines) that do it automatically for you.
> > When a line is filled, a newline is inserted, and then the order of
> > the text spread between several lines is what you expect:
> 
> OK, I want it to work like fill-paragraph, but I don't want to REALLY
> do fill-paragraph, because I don't want to modify the file AT ALL.

Right, and I want $5 million on my bank account, but it doesn't
happen ;-)

Look, as you know, the bidirectional display reorders on the buffer
text level, not on the glyph level.  This means that in this example:

      name2 1234 catag2 NOITPIRCSED-GNOL-YREV name3

when the display engine, marching from left to right, reaches the
beginning of the R2L text (the character N), and calls the bidi
reordering code, that code runs all the way to just before "name3",
then starts delivering the characters backwards, from right to left.
This ``run to the end of R2L text'' happens below the level that
produces glyphs for display.  Therefore, the code which does this run
has no idea where the visible part of the line ends.  If it bumps into
a newline, it stops and goes backward, which is why filling a
paragraph displays like you expect.  But to do what you want in a
truncated or continued line means I need to throw away the entire
design and implementation of the bidi reordering.  I think it's too
heavy price to pay for a relatively rare situation (mixed L2R and R2L
text that hits the window margin at the wrong place).

> From experience (with my visual Hebrew package) this is very annoying.
> Think of 3 very long (150, 270 and 150 characters) viewed on 80
> characters wide screen, It is very confusing to find the start of
> each line and to read upward 1 or 2 lines and go down again.

Again, _only_ if these long lines mix R2L and L2R, and then _only_ if
the text that crosses the 80-column border has its direction against
the base paragraph direction.

> > > Oops, the beginning of the Hebrew text disappeared.
> >
> > And this is significantly worse than if the _end_ of the text
> > disappears, because...?
> 
> Yes, it is definitely worse. First the the case of text that goes just
> a screen and half down. You'll have to scroll one page down, read a
> few lines upward, that scroll up, find the last line you read and
> continue upward, you may need scroll up once more for the beginning of
> the text. Second, consider the case of a very, very long text (more
> than 100 continuation lines), it is almost impossible to find its
> start with your way, while in my way it is just the normal way of
> scrolling down (I do it by half screen at a time).

Maybe you forgot that we have line-move-visual since Emacs 23.1.
Anyway, I agree that for any limitation it's possible to find a
use-case, however marginal, where that limitation will be very
annoying.  (Yes, I think that 100 continuation lines, all of them
having R2L text when the paragraph is L2R, is a rare case.)

> I don't think this issue is problematic per se. I think that if the
> solution for R2L scrolling is good (when all the paragraphs are R2L)
> then it can be applied even when combined with L2R paragraphs on the
> same screen without any annoyance to the user.

Thanks.  Then help me convince Richard ;-)