bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16647: Imprecisions with window-resizing cursors


From: N. Jackson
Subject: bug#16647: Imprecisions with window-resizing cursors
Date: Fri, 14 Feb 2014 12:13:16 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

martin rudalics <rudalics@gmx.at> writes:

> Maybe this depends on the window manager used?  Can someone else
> reproduce this behavior with emacs -Q:
>
> (progn
>   (scroll-bar-mode -1) (split-window-right) )
>
> Slowly move the mouse from left to right across the vertical line
> splitting the windows. Once the mouse goes past the black line, it's
> still shown as <=>, although clicking-and-dragging on that area won't
> have any effect.

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

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.

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

I hope this information helps.

Regards,
N.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]