bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

> I'm assuming "Genya" is another name of Evgeni's?

Hopefully.  My MUA calls him Evgkeni.

> (Or perhaps the
> construct of an overly busy mind?!)

Not overly.

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

I have no idea why this should matter.  Maybe `mouse-pixel-position'
calls interact in some strange way.

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

Can't you try with a real mouse?

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

I recently read in a thread on help-gnu-emacs:

  Horizontal scroll bar is missing entirely from window.

How would the OP use it without a mouse?  Or do we have a second
N. Jackson?

> or an implementation annotation to accompany the discussion
> of the bug (in which case I can safely ignore it for the time being).

The vertical border (including the feature that hovering the mouse over
the adjacent fringe or text on the left should allow to drag it) is IMHO
a very fragile construct and moreover absent when scrollbars are used.
Hence I'd rather shift the discussion of problems with the <=> cursor to
dividers which should not suffer these drawbacks.

martin