Re: Changes in frame/window code

[martin rudalics]

>> I still have no feeling for how hscrolling works with bidi text.  IIUC
>> with L2R and R2L paragraphs in the same window, like
>>
>> LLLLLLLLLLLLLLLLLLLLLL2RRRRRRRRRRRRRRRRRRR
>>
>>                RRRRRRR2LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>>
>> hscrolling will NOT preserve the aspect that the two "2" visually appear
>> above each other.  Correct?
>
> Yes.  As the hscroll amount grows, the characters in the L2R lines
> will move to the left, while characters in the R2L lines will move to
> the right.

I have to think about the possible implications of this.  Maybe there
are none but putting this model into my brain will take some time.

> It's a hard problem primarily because it's hard to know what is TRT,
> and there's no "prior art" to follow.

Because all the others keep the "2"s from my example fixed above each
other, I presume.

>> Did you check with a window containg say one huge L2R line and all
>> other lines short and one huge R2L line and all other lines short?
>
> Yes.  Again, this is just normal hscroll, which works with
> bidirectional text since v24.1.  The fact that hscroll is triggered by
> clicking the scroll bar does not matter, as long as the direction of
> the scroll is interpreted correctly.  The changes I made simply took
> care of translating the scroll-bar clicks to hscroll amount.

I didn't mean that you should check whether hscroll works.  What I meant
was to check whether the slider/thumb size really relates to the size of
the longest line of text, disregarding the fact that it is L2R or R2L.

> You need to reverse the meaning of START and END for the R2L case:
>
>     end = whole - w->hscroll * FRAME_COLUMN_WIDTH (WINDOW_XFRAME (w));
>     start = end - box_width;
>
> (Note that current-bidi-paragraph-direction returns the results at
> buffer's point, so you will need to temporarily go to the window's
> point marker.)

As soon as you have some spare time (I know you never do) please try it.

martin