emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes in frame/window code


From: Eli Zaretskii
Subject: Re: Changes in frame/window code
Date: Mon, 28 Jul 2014 17:25:08 +0300

> Date: Mon, 28 Jul 2014 15:57:15 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  > 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".
> 
> But if that R2L line starts on the right of the right window edge it's
> larger, I presume.

You mean, if it's hscrolled?  Yes, of course -- exactly like an L2R
line.

I feel there's some misunderstanding here, because I don't believe
you'd ask about such trivia.  What am I missing?  What's bothering
you?

Perhaps it will help if I say (something that should be obvious, but
maybe it's only obvious to me...) that an R2L line behaves wrt
hscrolling the same as an L2R line, except that it is reversed on
display.  E.g., when the amount of hscroll gets larger, and R2L line
moves to the right, thus removing from sight the first (rightmost on
display) characters of the line.

>  > 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.
> 
> Hmmm...  That would mean my calculations in
> 
>        whole = move_it_to (&it, -1, INT_MAX, window_box_height (w), -1,
>                         MOVE_TO_X | MOVE_TO_Y);
> 
> of set_horizontal_scroll_bar have a flaw.

No, I don't think there's a flaw.  The move_it_* family of functions
doesn't know about reversal of R2L lines on display, they think an R2L
line is displayed starting at the left margin of the window.  See the
commentary about that at the beginning of xdisp.c.

>  >> 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?
> 
> No.  The slider size repesents the width of the window with respect to
> the longest line shown in the window.  Try moving point through the
> first column within a window - the slider size should not change.

Then I don't see why you think this should change when there's
bidirectional text in the buffer.  The same arguments work in that
case as well.  R2L lines do not affect the window width in any way
that L2R lines don't.

>  > 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.
> 
> Is the size of the slider correct in the sense described above?

Yes.

> Then fixing the position should not be that difficult.

I never said it was difficult, just that it has to be on the C level,
not on the Lisp level, where I fixed the clicks on the scroll bar.

>  > (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.)
> 
> No idea.

Maybe Jan (CC'ed) can help us out.

> In any case I would have to tell GTK whether the "current text"
> (whatever that is) is L2R or R2L I suppose.

Yes, but we have current-bidi-paragraph-direction for that.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]