Re: Changes in frame/window code

[martin rudalics]

>> Sounds pretty hairy, tho ...  With bidi text as above do you have a
>> fixed text width?
>
> I said "simple", didn't I?  The width is not fixed.
>
>> In which (virtual L2R) column does R2L text start?
>
> Sorry, I don't understand the question.  Are you asking about the
> "normal" display of R2L text, or are you asking about scrolling?

If you have


L2R text here ....

           ..... and R2L text here what is the L2R position after here?


If the text width is not fixed how can I calculate the width of a R2L
line as it is displayed including any space between the left edge of the
display until where the text ends?

> What I added only works well if the entire visible portion of the
> buffer has the same paragraph direction, either L2R or R2L.  If you
> have paragraphs in both directions visible, they will scroll in
> opposite directions (because columns are counted in logical order, not
> in visual order).

IIUC this means that the slider width must be calculated paragraph-wise
and position and size of the slider are meaningful only with respect to
the paragraph point is currently in.

> Horizontal scrolling of mixed-direction paragraphs is a hard problem.
> A WYSIWYG word processor could behave as if the text width were fixed
> (that's what happens on paper), but Emacs is not a WYSIWYG word
> processor and supports line continuation.

Admittedly, horizontal scroll bars are not very useful when line
continuation is on.

> So it's not clear what to
> do here.  The code I added is a stop-gap: it at least will DTRT when
> the text on screen has the same base direction.  We must have at least
> that, or we will be lynched.

Does it work now in that case?

martin