bug#16647: Imprecisions with window-resizing cursors

[nljlistbox2@gmail.com (N. Jackson)]

Hi Martin,

At 05:17 -0400 on Saturday 2014-02-22, martin rudalics wrote:

>> Okay, I have applied the patch (on top of GNU Emacs 24.3.50
>> (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8) of 2014-02-19 Repository
>> revision: 116484)
>>
>> With the patch I see the same behaviour I described above.
>
> Genya - can you try once more whether the patch applies now (and, if not,
> why so) on your system and which results you get?

I'm assuming "Genya" is another name of Evgeni's? (Or perhaps the
construct of an overly busy mind?!)

>>> Evaluating this returns (8 . 0) here, the cdr of which amounts to the
>>> width of one character on my frame.  So here I have an 8 pixel-wide
>>> corridor entirely in the left window where I am "on the vertical line"
>>> (which occupies virtually the 7 right pixels of the right fringe of the
>>> window on the left).
>>
>> Here I get (6 . 0).
>
> What does M-: (frame-char-width) give on your system?

6 (#o6, #x6, ?\C-f)

>> I get (6 . 0) (with initial i = 400).
>>
>> Nevertheless, I can almost never get the <=> handle when I approach from
>> the left.
>
> You could try slowing down the movement by (1) starting with a higher
> initial value for i (so you don't have to wait too long) and (2)
> increasing the `sit-for' argument so you can see more of the cursor
> shape.  This way we would know whether the cursor is actually shown in
> the expected shape as long as it is within the grabbable width.

I had to put the sit-for immediately after the set-mouse-pixel-position
rather than immediately before it or I didn't get a <=> at all --
presumably there wasn't enough time to update the cursor the way you had
it written?

Then, with a sit-for of 0.2 seconds, I got the <=> perfectly fine,
exactly where expected, going in both directions. I still almost never
see it when I move the mouse manually, going from left to right --
possibly a defect in my trackpad?

> Anyway, in the future I recommend to use window dividers instead of the
> "vertical line overlaying the fringe" approach.

Sorry, I don't understand. Do you intend that to be advice for the user,
(In which case it is moot for me at least, as the only time I ever use a
mouse on my computer is to get around a resume-from-suspend bug in
Fedora, which locks out the keyboard until a mouse button has been
pressed.), or an implementation annotation to accompany the discussion
of the bug (in which case I can safely ignore it for the time being).

N.