bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 06:32 -0400 on Sunday 2014-02-16, martin rudalics wrote:

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

Well, my eyesight isn't up for counting the pixels on this display, but
if the divider is the correct 24 pixels wide with this recipe, then the
<=> handle is displayed in a region with a width of maybe 30 pixels. It
doesn't appear until the mouse has crossed over into the vertical bar,
but it continues to be displayed as the mouse continues to move beyond
the width of the vertical bar.

To the right of the vertical bar, it is displayed well in to the left
fringe of the right window. To the left of the vertical bar it is
displayed over the right "border" of the scroll bar (but not as far to
the left as the slider thing inside the scroll bar).

In these regions, beyond the width of the divider, when it is clicked it
turns immediately to a normal mouse cursor, and no dragging is
possible. This is Evgeni's original bug, I believe.

Note: I am defining the location of the <=> cursor as the centre of it.

>> With this recipe I see nothing wrong at all (except for the
>> sluggishness).
>
> How would you describe the sluggishness?

I am not seeing the sluggishness any more (after a restart of the
computer). The Emacs windowing seems roughtly as snappy now as other
running applications.

What I was previously seeing was when maximaizing and restoring an Emacs
frame (which is done here by pressing the logo key and the up or down
arrow key), instead of the frame instantly appearing at its new size, I
could see a very jerky animation of its resizing, and had to actually
wait for it to be finished.

Likewise, Gnome 3, amongst the extraordinary annoyances of its user
interface, has no application menus, so to run those programs that I
don't run from the command line, I have to hit the logo key to get a
completion text box in which I type the name of the program. While this
text box is displayed, all the open windows shrink to medium-sized
thumnbnails that are desplayed on the "desktop", and the shrinking of
Emacs frames into this display was also very much slower than I have
ever seen any other program be.

But as I said, I can no longer observe this sluggishness, but I don't
know what has changed. Sorry.

>>>> 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.
                                                     ^^^^
I should have said "right" here of course.                                      
               

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

Recipe:

Emacs -Q

M-: (progn (scroll-bar-mode -1) (split-window-right) )

Drag vertical line as far as it will go to the right.

Approach (and cross) vertical line with mouse cursor from the
left. (Bug: I do not see the mouse cursor turn into the <=> handle.)

Approach (and cross) vertical line with mouse cursor from the right. (I
see the mouse cursor correctly turn into <=> handle.)

N.