bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

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