bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

> On GTK3 with Emacs built from trunk on 2014-02-10, I do not see the
> symptoms above exactly, but I do see another bug.
>
> With the recipe above:
>
> lag in appearance of <=> handle (probably okay?)
> ================================================
> As the mouse cursor crosses the vertical line there _is_ a distinct lag
> in the appearance of the <=> handle, so that it _does_ appear to the
> left or right of the line (depending upon which direction the mouse was
> moving), unless the mouse movement is _extremely_ slow. I don't think
> this behaviour is particularly unusual (although it seems part of a
> distinct sluggishness in the windowing interface

... maybe due to the fact that dragging now happens pixelwise ...

> that wasn't there in
> Emacs 24.3.1). The <=> handle never first appears further from the
> vertical line than (roughly?) the width of the fringe.

From reading the code and from my personal experience (GTK, Lucid, Motif
and Windows) with emacs -Q:

(1) When moving the mouse from left to right the <=> appears as soon as
    the mouse enters the right fringe of the window on the left and
    disappears when I cross the vertical border.

(2) When moving the mouse from right to left the <=> appears as soon as
    the mouse crosses the vertical border and disappears when leaving
    the right fringe of the window on the left.

I see no lag when I just move the mouse over the border.  I see a lag
only when I'm actually dragging the border.  Maybe our mouse settings
are different.

> That is, the <=>
> handle doesn't appear at all if one moves the mouse over the vertical
> line too quickly, and this seems okay too.

I see the same here.

> Clicking on and dragging with <=> handle works correctly consistently
> =====================================================================
> Clicking on and dragging the <=> handle works every time. I cannot
> duplicate any case in which doing so has no effect, _unless_ the
> vertical line is already as far to the left or right in the frame as it
> will go, in which case one can only drag it in one direction, which
> behaviour is obviously correct.

Same here.

> 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 hope this information helps.

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

Thanks, martin