Re: Changes in frame/window code

[Eli Zaretskii]

> Date: Tue, 29 Jul 2014 11:20:24 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  >> 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.

As long as we use logical-order columns, there really isn't any
alternative to this behavior.

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

Yes, because all the others (those I know of) are WYSIWYG word
processors, where the page size has a well-defined meaning and is
fixed within a given document.

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

Line width calculations, like column calculations, are unaffected by
bidi.  These calculations are done using buffer text in its logical
order, so the way text is displayed cannot have any effect on that.

So if we can correctly compute the length of the longest line at all,
we can do it with any text, bidi or not.  Therefore, the size of the
thumb will always be true (and is, I checked that, of course).

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

I can only try this on MS-Windows.