Re: Changes in frame/window code

[martin rudalics <rudalics@gmx.at>]

 >> (1) When dragging I cannot move the slider entirely to the right and
 >>       make the first column of R2L lines visible until I release the mouse
 >>       button.  I suppose this is due to some off-by-one failure here but
 >>       there might be more to it.
 >
 > I'm not sure this is at all related to R2L lines.  I wrote a trivial
 > function which just displays the mouse event, and bound it to clicks
 > on the horizontal scroll bar.  When I drag the scroll bar, even in an
 > entirely L2R buffer, I see some strange phenomena: e.g., more often
 > than not, when I drag the bar all the way to the right, releasing the
 > mouse button without moving the mouse reports slightly different
 > coordinates than the ones reported before releasing the mouse.
 > Moreover, many time the 2nd coordinate reported after releasing the
 > mouse is -1.  Try it.  Maybe it's Windows-specific, I don't know.

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

 > Btw, it looks like the information returned by mouse events on the
 > horizontal scroll bar is not described anywhere, not even in NEWS.
 > Your use of (cdr (nth 2 start-position)) in
 > scroll-bar-horizontal-drag-1 got my jaw dropped for a few seconds,
 > before I realized it was not the Y coordinate...

I'm not sure yet where to eventually put this and whether it's the right
solution at all.  IIUC the scroll bar area on the right of the thumb stands
for w->hscroll in R2L text and this was the easiest way to pass on that
value from what GetScrollInfo returns without consing.  If you have any
suggestion how to handle this cleanly I'd be all ears.

 > Also, I don't understand the subtlety of +1 in setting up the scroll
 > info, e.g.:
 >
 >    /* Allow nPage to be one larger than nPos so we don't allow to scroll
 >       an already fully visible buffer.  */
 >    si.nPage = min (portion, si.nMax) + 1;
 >    si.nPos = min (position, si.nMax);
 >
 > The comment doesn't correspond to the code, and I couldn't understand
 > what's behind this trick.

The idea is that if I do not add 1 to nPage, the displayed thumb gets
too small.  This means that although I see the entire text I can still
scroll it and make the first column disappear, which is distracting.
I've not found a better solution yet.  In any case, this is my probably
poor interpretation of how SetScrollInfo works (compare
http://msdn.microsoft.com/en-us/library/windows/desktop/bb787595%28v=vs.85%29.aspx
The nPage member must specify a value from 0 to nMax - nMin +1. The nPos
member must specify a value between nMin and nMax - max( nPage– 1, 0)).
And yes, the comment is obviously wrong.

 >> (2) Sometimes during dragging the slider starts moving for-/backward in
 >>       some erratic fashion.  I'm not yet sure whether this is caused by an
 >>       hmargin issue or something else.
 >
 > I could only see this in the very first line of the tutorial.  There
 > was an old and very subtle bug in xdisp.c, revealed by
 > set_horizontal_scroll_bar, which caused broken cursor motion in that
 > line.  This is now fixed in r117711 on the trunk.  If you still see
 > something like that, and it's not related to the few L2R lines in the
 > tutorial, please report a bug with the recipe.

I can see it only with my personal setup here.  With emacs -Q I can
reproduce it by setting

(set-frame-parameter nil 'right-divider-width 7)

and scrolling the tutorial in the left window of a C-x 3 split frame.

 >> (3) Line 121 (written backwards as)
 >>
 >> אם הסמן נמצא באמצע מילה, M-f זז לסוף המילה. אם הסמן נמצא בין שתי מלים,
 >>
 >>      of the tutorial presents a special problem: When I'm repeatedly doing
 >>      `next-line' on the rightmost column before that line and are about
 >>      to move to that line I enter some strange sort of loop with the
 >>      slider in the center of the scroll bar trying to move back- and
 >>      forward.  C-g gets me out of it but I can't tell so far why I'm stuck
 >>      there.
 >
 > This is now fixed in r117447 on the release branch.  The previous
 > revision fixed bug #18277.

Fine.  These work well now.

martin