Re: Changes in frame/window code

[Eli Zaretskii]

> Date: Mon, 18 Aug 2014 18:11:19 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  > but it's still unclear to me why this problem is not visible
>  > in L2R buffers.
> 
> Because for L2R I count the part from the leftmost position to the start
> of the scroll bar thumb which is unaffected by the size of the thumb?

If so, we have an off-by-one error somewhere, since these are just
pixel values with nothing magic about them.

>  >    . The erratic behavior seems to be due to our own code resetting the
>  >      thumb position right after I drag the thumb to some new position.
>  >      The code which causes this seems to be -- surprise, surprise --
>  >      set_horizontal_scroll_bar that calls
>  >      set_horizontal_scroll_bar_hook passing it the previous position.
>  >      I didn't yet figure out why this affects only R2L lines.
> 
> You mean that w->hscroll has its previous value in
> 
>        start = w->hscroll * FRAME_COLUMN_WIDTH (WINDOW_XFRAME (w));
> 
> in xdisp.c although w->hscroll was in between changed by
> `scroll-bar-horizontal-drag-1'?

I didn't analyze this further, but it should be easy to verify.

>  >    . If point is on an empty line, the problem doesn't happen.
> 
> Confirmed.
> 
>  >      Likewise, if I drag the scroll bar of a non-selected window, the
>  >      problem doesn't happen, either.
> 
> Confirmed, too.  Weird.  Do we somewhere try more hard to autoscroll
> when the window is selected?

See hscroll_windows: we scroll all windows in a window tree.

>  >      Maybe we call the scroll-bar hook
>  >      too early, without giving redisplay the chance to hscroll all the
>  >      windows?
> 
> Wouldn't in such case the result be that some windows fail to get
> scrolled?

Isn't that exactly what we observe here?