Re: Changes in frame/window code

[martin rudalics <rudalics@gmx.at>]

 >> I suppose the -1 is due to the
 >>
 >>         si.nPage = min (portion, si.nMax) + 1;
 >>
 >> you mention below and that's likely the culprit for the effect described
 >> in (1).
 >
 > Perhaps,

It happens without the "+ 1" as well, so this is not responsible.

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

 > I don't think your solution is unclean (the Y coordinate makes no
 > sense for horizontal scroll bar events), I just wish it were
 > documented, at least in NEWS.  It doesn't take more than a few lines.

But I've just put it in and only in the Windows port because you
proposed to try it.  As soon as I've rewritten all affected ports I'll
document it.

 > On Windows XP, I cannot see this at all.

I see it on Windows XP.

 > On Windows 7, I always see
 > this on the 1st line of the tutorial, even without setting
 > right-divider-width, and I see it when point is on most (but not all,
 > see below) lines if I do set right-divider-width.

I do so too, meanwhile.  But setting the right divider width to non-zero
makes it happen immediately here on the first line of the tutorial.

 > Alas, I'm not your guy in these matters, as I'm clueless as to GUI
 > programming in general and Windows GUI in particular.  So I just
 > sprinkled fprintf lines in suspect places and watched them while
 > exercising the erratic behavior of the scroll bar.  Here are some
 > observations that might help you figure this out:
 >
 >    . 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'?

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

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

 > (Btw, note that I needed a small change to be able to scroll correctly
 > non-selected windows; see r117712 on the trunk.)

Thanks, I forgot about these.

 > (Btw2, when is x_horizontal_scroll_bar_report_motion called?  I
 > couldn't see it being called when the scroll bar is used.)

I don't have the slightest idea when and whether I should call it.  I
had changed its code to return the part right of the thumb as well only
to find out that it never got called so I left the code unchanged in my
last commit.

martin