Re: Changes in frame/window code

[Eli Zaretskii]

> Date: Mon, 28 Jul 2014 11:26:02 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  >> 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?

If you include the space on the left, then the width of an R2L display
line is always exactly equal to the window width.  This is how the
display engine computes the width of the stretch glyph that represents
"the space on the left".

If you want the line width without the stretch, then you calculate it
exactly like with L2R lines: columns and line widths are computed in
the logical order.

>  > 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.

Yes.  But that is true for strictly L2R text as well, no?  I mean, the
size of the scroll-bar thumb should depend on the width of the line at
point, right?

>  > 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.

Of course, but that's not what I meant.  I meant to point out how
Emacs in its default text display modes differs from WYSIWYG word
processors, where fixed width of the text comes in naturally.

>  > 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?

It does work correctly when you click on the scroll-bar arrows or
between them and the slider.

It doesn't work when you drag the slider.  When you drag the slider,
the text is scrolled in the wrong direction.  The underlying problem
is that the slider starts in a wrong position -- it should be all the
way to the right, not to the left.  AFAIU, this can only be fixed on
the C level.

(Btw, shouldn't GTK scroll bars already support bidirectional text out
of the box?  Perhaps you need to set some flag(s) to get that.)