GNU bug report logs -
#16647
Imprecisions with window-resizing cursors
Previous Next
Full log
Message #14 received at 16647 <at> debbugs.gnu.org (full text, mbox):
>> 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
This bug report was last modified 10 years and 327 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.