bug#16647: Imprecisions with window-resizing cursors

[martin rudalics <rudalics@gmx.at>]

 >> Can you please try conducting the same experiments with emacs -Q
 >>
 >> (set-frame-parameter nil 'right-divider-width 6)
 >>
 >> and with scrollbars en-/and disabled?
 >
 > emacs -Q
 > M-: (set-frame-parameter nil 'right-divider-width 6)
 > M-x split-window-right
 >
 > With this I see Evgeni's original bug -- when the <=> handle first
 > appears beyond the vertical line, clicking on it and dragging has no
 > effect, if just disappears and returns to a normal cursor. It's
 > disorienting behaviour but I think it might be due to the lag --
 > i.e. maybe it's about to turn back to the normal mouse cursor but hasn't
 > gotten around to actually doing so yet.

Suppose you

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

Then the <=> shows for a width of 24 pixels here.  Doesn't it with your
setup?

 > With this recipe I see nothing wrong at all (except for the
 > sluggishness).

How would you describe the sluggishness?

 > Also I have a slight amendment to what I wrote earlier about my "Another
 > bug":
 >
 >>> Another bug =========== When the vertical line is as far to the right
 >>> in the frame as it will go (i.e., when the right window is as narrow
 >>> as permitted), then the <=> handle only appears when the mouse cursor
 >>> approaches the vertical line from the right. If the mouse cursor
 >>> approaches the vertical line from the left, the <=> handle fails to
 >>> appear. (Ditto with "left" and "right" reversed in that statement.)
 >> Interesting.  I cannot observe that here.
 >
 > I double checked this. I definitely see this happening, but I was
 > mistaken about the "ditto". When the vertical line is as far to the left
 > as it will go, the <=> handle only appears when the mouse cursor
 > approaches the vertical line from the _right_ -- the same direction as
 > for the case with the vertical line as far to the left as it will go.

Double checked this too.  I still can't see what you describe.

martin