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

From: martin rudalics <[email-masked]>
Date: Thu, 06 Feb 2014 11:26:36 +0100

>> I can't reproduce that neither with GTK+ 3.4.2 nor on Windows XP.  The
 >> cursor changes shape to <=> within one frame column distance on the left
 >> of the vertical border (the "grabbable_width" in coordinates_in_window
 >> IIUC) till right after that border.  When the cursor shows as <=> I can
 >> also drag the border.  Clicking on the border doesn't have any effect.
 >
 > Sometimes it works fine. Perhaps you could try moving the border to different locations.

Still seeing what I said above: "When the cursor shows as <=> I can also
drag the border."  You could try one of the following:

(1) Check whether setting the right-divider frame parameter to 1 suffers
     from the same problem.

(2) Try putting `coordinates-in-window-p' in a loop where you simulate
     (by incrementing the car of the first argument) the course of the
     mouse and display the return value via a message.

(3) In window.c DEFVAR_LISP a new variable, in coordinates_in_window set
     that variable to the value coordinates_in_window is about to return,
     display the value of that variable in the modeline, and then move
     the mouse to find out what it reports.

 >> Emacs doesn't show a vertical resize cursor on the mode- or header-line
 >> (for historical reasons, I presume).  You can now use bottom dividers to
 >> show such a cursor.
 >
 > Normally I'd say you know better, except I recall seeing a
 >
 >                              ^
 >                              I
 >                              v
 >
 > cursor on mode-lines, for as long as I remember.

Hmmm... on 2013-11-30 I have

* xterm.h (struct x_output): Add vertical_drag_cursor.

martin