Subject: Re: bug#16647: Imprecisions with window-resizing cursors

From: martin rudalics <[email-masked]>
Date: Fri, 14 Feb 2014 19:25:36 +0100

> 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