bug#16647: Imprecisions with window-resizing cursors

bug#16647: Imprecisions with window-resizing cursors

[E Sabof]

On current trunk version, from emacs -Q

1)

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

Slowly move the mouse from left to right across the vertical line splitting the windows. Once the mouse goes past the black line, it's still shown as <=>, although clicking-and-dragging on that area won't have any effect.

2)

C-x 2

Move the cursor from top to bottom, across the mode-line. Once the cursor enters the mode-line, it won't change to a "resize" cursor, although it's already possible to drag.

3)

C-x 1
(set-window-margins nil (car (window-margins)) 10)
C-x 3

Move the cursor from right to left, across the divider. Once the mouse enters the right margin, it will still be displayed as <=>, although it's not possible to resize by clicking there.

Evgeni

GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.4) of 2014-02-05 on ubuntu

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > On current trunk version, from emacs -Q
 >
 > 1)
 >
 > (progn
 >   (scroll-bar-mode -1)
 >   (split-window-right)
 >   )
 >
 > Slowly move the mouse from left to right across the vertical line splitting the windows. Once the mouse goes past the black line, it's still shown as <=>, although clicking-and-dragging on that area won't have any effect.

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.

 > 2)
 >
 > C-x 2
 >
 > Move the cursor from top to bottom, across the mode-line. Once the cursor enters the mode-line, it won't change to a "resize" cursor, although it's already possible to drag.

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.

 > 3)
 >
 > C-x 1
 > (set-window-margins nil (car (window-margins)) 10)
 > C-x 3
 >
 > Move the cursor from right to left, across the divider. Once the mouse enters the right margin, it will still be displayed as <=>, although it's not possible to resize by clicking there.

This is a arguably a bug.  I checked in a fix.  Please try again.

Thanks, martin

bug#16647: Imprecisions with window-resizing cursors

[Evgkeni Sampelnikof]

martin rudalics <rudalics@gmx.at> writes:

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

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

> This is a arguably a bug.  I checked in a fix.  Please try again.

This works fine now, thanks.

Evgeni

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

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

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> From: Evgkeni Sampelnikof <esabof@gmail.com>
> Date: Thu, 06 Feb 2014 09:21:40 +0000
> Cc: 16647@debbugs.gnu.org
> 
> > 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.

Not on MS-Windows.  I tried Emacs 22, 23, and 24, and none of them
does that.

bug#16647: Imprecisions with window-resizing cursors

[Stefan Monnier]

> Normally I'd say you know better, except I recall seeing a

>                              ^
>                              I
>                              v

> cursor on mode-lines, for as long as I remember.

Indeed, Debian's emacs22 and emacs24 both do that.


        Stefan

bug#16647: Imprecisions with window-resizing cursors

[E Sabof]

martin rudalics <rudalics@gmx.at> writes:

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

No change.

> (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.
>

(progn
  (scroll-bar-mode -1)
  (require 'cl-lib)
  (run-with-timer 0 0.1
                  (lambda ()
                    (let ((win-list (window-list))
                          (func (apply-partially
                                 'coordinates-in-window-p
                                 (cdr (mouse-position)))))
                      (message "%s" (cl-find-if func win-list))))))

I've tried the snippet above. There where imprecisions, but shouldn't that be expected, given `coordinates-in-window-p' returns characters and not pixels? Should I try something similar with `track-mouse' and pixels?

Evgeni

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

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

Sorry, the parameter is called right-divider-width.  Does it still show
a <-> cursor when moving the mouse to the right and that is 1?  What
happens when you increase the width?

 >> (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.
 >>
 >
 > (progn
 >   (scroll-bar-mode -1)
 >   (require 'cl-lib)
 >   (run-with-timer 0 0.1
 >                   (lambda ()
 >                     (let ((win-list (window-list))
 >                           (func (apply-partially
 >                                  'coordinates-in-window-p
 >                                  (cdr (mouse-position)))))
 >                       (message "%s" (cl-find-if func win-list))))))
 >
 > I've tried the snippet above. There where imprecisions, but shouldn't that be expected, given `coordinates-in-window-p' returns characters and not pixels?

I forgot that `coordinates-in-window-p' can't be given pixels as
arguments.  Please try the patch below.

 > Should I try something similar with `track-mouse' and pixels?

And the pixelized version of `coordinates-in-window-p', if possible.  We
want to know what that function returns when your mouse is right after
the border.

martin

=== modified file 'src/window.c'
--- src/window.c	2014-02-07 10:55:28 +0000
+++ src/window.c	2014-02-07 18:05:15 +0000
@@ -1401,13 +1401,15 @@


  DEFUN ("coordinates-in-window-p", Fcoordinates_in_window_p,
-       Scoordinates_in_window_p, 2, 2, 0,
+       Scoordinates_in_window_p, 2, 3, 0,
         doc: /* Return non-nil if COORDINATES are in WINDOW.
  WINDOW must be a live window and defaults to the selected one.
  COORDINATES is a cons of the form (X . Y), X and Y being distances
  measured in characters from the upper-left corner of the frame.
  \(0 . 0) denotes the character in the upper left corner of the
-frame.
+frame.  Third argument PIXELWISE non-nil means interpret coordinates
+pixelwise.
+
  If COORDINATES are in the text portion of WINDOW,
     the coordinates relative to the window are returned.
  If they are in the mode line of WINDOW, `mode-line' is returned.
@@ -1418,7 +1420,7 @@
    `vertical-line' is returned.
  If they are in the windows's left or right marginal areas, `left-margin'\n\
    or `right-margin' is returned.  */)
-  (register Lisp_Object coordinates, Lisp_Object window)
+  (register Lisp_Object coordinates, Lisp_Object window, Lisp_Object pixelwise)
  {
    struct window *w;
    struct frame *f;
@@ -1430,10 +1432,16 @@
    CHECK_CONS (coordinates);
    lx = Fcar (coordinates);
    ly = Fcdr (coordinates);
-  CHECK_NUMBER_OR_FLOAT (lx);
-  CHECK_NUMBER_OR_FLOAT (ly);
-  x = FRAME_PIXEL_X_FROM_CANON_X (f, lx) + FRAME_INTERNAL_BORDER_WIDTH (f);
-  y = FRAME_PIXEL_Y_FROM_CANON_Y (f, ly) + FRAME_INTERNAL_BORDER_WIDTH (f);
+  CHECK_NUMBER (lx);
+  CHECK_NUMBER (ly);
+  x = ((!NILP (pixelwise)
+	? XINT (lx)
+	: FRAME_PIXEL_X_FROM_CANON_X (f, lx))
+       + FRAME_INTERNAL_BORDER_WIDTH (f));
+  y = ((!NILP (pixelwise)
+	? XINT (ly)
+	: FRAME_PIXEL_Y_FROM_CANON_Y (f, ly))
+       + FRAME_INTERNAL_BORDER_WIDTH (f));

    switch (coordinates_in_window (w, x, y))
      {

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > Indeed, Debian's emacs22 and emacs24 both do that.

Indeed.  Maybe it checks the shape of the object.  Anyway, IIUC the
vertical drag cursor is shown only when no text appears under the mouse.
So I suppose the current behavior is intentional.

martin

bug#16647: Imprecisions with window-resizing cursors

[E Sabof]

martin rudalics <rudalics@gmx.at> writes:

> Sorry, the parameter is called right-divider-width.  Does it still show
> a <-> cursor when moving the mouse to the right and that is 1?  What
> happens when you increase the width?

I didn't manage to get the patch working for some reason. Assuming the
below is equivalent, there is still no change with right-divider-width.

The window I get in the messages, may also be off by a few pixels.
(Although the cursor doesn't change at all with the above snippet).

Evgeni

(progn
  (setq-local track-mouse t)
  (scroll-bar-mode -1)
  (global-set-key (kbd "<mouse-movement>")
                  (lambda (event)
                    (interactive "e")
                    (message "%s" (car (event-end event))))))

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > I didn't manage to get the patch working for some reason. Assuming the
 > below is equivalent, there is still no change with right-divider-width.
 >
 > The window I get in the messages, may also be off by a few pixels.

Here on Windows XP the window is never "off".

 > (Although the cursor doesn't change at all with the above snippet).

Probably mouse tracking disables showing the <=> cursor.

Maybe this depends on the window manager used?  Can someone else
reproduce this behavior with emacs -Q:

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

Slowly move the mouse from left to right across the vertical line
splitting the windows. Once the mouse goes past the black line, it's
still shown as <=>, although clicking-and-dragging on that area won't
have any effect.

martin

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

martin rudalics <rudalics@gmx.at> writes:

> Maybe this depends on the window manager used?  Can someone else
> reproduce this behavior with emacs -Q:
>
> (progn
>   (scroll-bar-mode -1) (split-window-right) )
>
> Slowly move the mouse from left to right across the vertical line
> splitting the windows. Once the mouse goes past the black line, it's
> still shown as <=>, although clicking-and-dragging on that area won't
> have any effect.

On GTK3 with Emacs built from trunk on 2014-02-10, I do not see the
symptoms above exactly, but I do see another bug.

With the recipe above:

lag in appearance of <=> handle (probably okay?)
================================================ 
As the mouse cursor crosses the vertical line there _is_ a distinct lag
in the appearance of the <=> handle, so that it _does_ appear to the
left or right of the line (depending upon which direction the mouse was
moving), unless the mouse movement is _extremely_ slow. I don't think
this behaviour is particularly unusual (although it seems part of a
distinct sluggishness in the windowing interface that wasn't there in
Emacs 24.3.1). The <=> handle never first appears further from the
vertical line than (roughly?) the width of the fringe. That is, the <=>
handle doesn't appear at all if one moves the mouse over the vertical
line too quickly, and this seems okay too.

Clicking on and dragging with <=> handle works correctly consistently
=====================================================================
Clicking on and dragging the <=> handle works every time. I cannot
duplicate any case in which doing so has no effect, _unless_ the
vertical line is already as far to the left or right in the frame as it
will go, in which case one can only drag it in one direction, which
behaviour is obviously correct.

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

I hope this information helps.

Regards,
N.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > On GTK3 with Emacs built from trunk on 2014-02-10, I do not see the
 > symptoms above exactly, but I do see another bug.
 >
 > With the recipe above:
 >
 > lag in appearance of <=> handle (probably okay?)
 > ================================================
 > As the mouse cursor crosses the vertical line there _is_ a distinct lag
 > in the appearance of the <=> handle, so that it _does_ appear to the
 > left or right of the line (depending upon which direction the mouse was
 > moving), unless the mouse movement is _extremely_ slow. I don't think
 > this behaviour is particularly unusual (although it seems part of a
 > distinct sluggishness in the windowing interface

... maybe due to the fact that dragging now happens pixelwise ...

 > that wasn't there in
 > Emacs 24.3.1). The <=> handle never first appears further from the
 > vertical line than (roughly?) the width of the fringe.

 From reading the code and from my personal experience (GTK, Lucid, Motif
and Windows) with emacs -Q:

(1) When moving the mouse from left to right the <=> appears as soon as
     the mouse enters the right fringe of the window on the left and
     disappears when I cross the vertical border.

(2) When moving the mouse from right to left the <=> appears as soon as
     the mouse crosses the vertical border and disappears when leaving
     the right fringe of the window on the left.

I see no lag when I just move the mouse over the border.  I see a lag
only when I'm actually dragging the border.  Maybe our mouse settings
are different.

 > That is, the <=>
 > handle doesn't appear at all if one moves the mouse over the vertical
 > line too quickly, and this seems okay too.

I see the same here.

 > Clicking on and dragging with <=> handle works correctly consistently
 > =====================================================================
 > Clicking on and dragging the <=> handle works every time. I cannot
 > duplicate any case in which doing so has no effect, _unless_ the
 > vertical line is already as far to the left or right in the frame as it
 > will go, in which case one can only drag it in one direction, which
 > behaviour is obviously correct.

Same here.

 > 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 hope this information helps.

Yes.  Can you please try conducting the same experiments with emacs -Q

(set-frame-parameter nil 'right-divider-width 6)

and with scrollbars en-/and disabled?

Thanks, martin

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

martin rudalics <rudalics@gmx.at> writes:

> Can you please try conducting the same experiments with emacs -Q
>
> (set-frame-parameter nil 'right-divider-width 6)
>
> and with scrollbars en-/and disabled?

emacs -Q
M-: (set-frame-parameter nil 'right-divider-width 6)
M-x split-window-right

With this I see Evgeni's original bug -- when the <=> handle first
appears beyond the vertical line, clicking on it and dragging has no
effect, if just disappears and returns to a normal cursor. It's
disorienting behaviour but I think it might be due to the lag --
i.e. maybe it's about to turn back to the normal mouse cursor but hasn't
gotten around to actually doing so yet.

I do _not_ see my "Another bug" with this configuration -- when the
vertical line is at its extreme left or right position, it doesn't
matter from which side one approaches it, one still get's the <=> handle
displayed.

emacs -Q
M-: (progn
  (scroll-bar-mode -1) (set-frame-parameter nil 'right-divider-width 6)
  (split-window-right) )

With this recipe I see nothing wrong at all (except for the
sluggishness).


Also I have a slight amendment to what I wrote earlier about my "Another
bug":

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

bug#16647: Imprecisions with window-resizing cursors

[Drew Adams]

> Maybe this depends on the window manager used?  Can someone else
> reproduce this behavior with emacs -Q:
> 
> (progn
>    (scroll-bar-mode -1)
>    (split-window-right))
> 
> Slowly move the mouse from left to right across the vertical line
> splitting the windows. Once the mouse goes past the black line, it's
> still shown as <=>, although clicking-and-dragging on that area
  ^^^^^^^^^^^^^^^^^^
> won't have any effect.

That's not what I see, with Windows 7.

As soon as the mouse pointer gets to the solid black line, the
pointer changes from <=> to the normal outline arrow that points
to the upper left.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 >> Can you please try conducting the same experiments with emacs -Q
 >>
 >> (set-frame-parameter nil 'right-divider-width 6)
 >>
 >> and with scrollbars en-/and disabled?
 >
 > emacs -Q
 > M-: (set-frame-parameter nil 'right-divider-width 6)
 > M-x split-window-right
 >
 > With this I see Evgeni's original bug -- when the <=> handle first
 > appears beyond the vertical line, clicking on it and dragging has no
 > effect, if just disappears and returns to a normal cursor. It's
 > disorienting behaviour but I think it might be due to the lag --
 > i.e. maybe it's about to turn back to the normal mouse cursor but hasn't
 > gotten around to actually doing so yet.

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?

 > With this recipe I see nothing wrong at all (except for the
 > sluggishness).

How would you describe the sluggishness?

 > Also I have a slight amendment to what I wrote earlier about my "Another
 > bug":
 >
 >>> 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.

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

martin

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.

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 14:17 -0400 on Sunday 2014-02-16, N. Jackson wrote:

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

I tested again running GNU Emacs 24.3.50 (x86_64-unknown-linux-gnu, GTK+
Version 3.8.8) of 2014-02-19 Repository revision: 116484
lekktu@gmail.com-20140219210406-y2s7lx244ojfl5on

With the recipe above I no longer see the bug. The <=> handle now never
seems to be displayed much beyond the vertical line, and it seems I can
always click and drag it.

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

Regardless of where the vertical line is, it is now almost impossible to
get the <=> handle to appear at all when approaching the vertical line
from the left -- I get it once in about fifty attempts. When approaching
the vertical line from the right, the <=> handle appears normally (and
it now appears normally when the vertical line is all the way to the
left as well).

N.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]

 > Regardless of where the vertical line is, it is now almost impossible to
 > get the <=> handle to appear at all when approaching the vertical line
 > from the left -- I get it once in about fifty attempts. When approaching
 > the vertical line from the right, the <=> handle appears normally (and
 > it now appears normally when the vertical line is all the way to the
 > left as well).

If you can apply the patch I posted earlier (and I attach here again)
you could try the following snippet with emacs -Q:

(let ((i 200)
       (window-on-left (selected-window))
       (window-on-right (split-window-right))
       (lhits 0)
       (rhits 0))
   (tooltip-mode -1)
   (scroll-bar-mode -1)
   (set-mouse-pixel-position (selected-frame) i 200)
   (while (car (setq position (cdr (mouse-pixel-position))))
     (let ((coordinates (coordinates-in-window-p position window-on-left t)))
       (when (eq coordinates 'vertical-line)
	(setq lhits (1+ lhits))))
     (let ((coordinates (coordinates-in-window-p position window-on-right t)))
       (when (eq coordinates 'vertical-line)
	(setq rhits (1+ rhits))))
     (sit-for 0.001)
     (set-mouse-pixel-position
      (selected-frame) (setq i (1+ i)) 200))
   (cons lhits rhits))

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

(let ((i 600)
       (window-on-left (selected-window))
       (window-on-right (split-window-right))
       (lhits 0)
       (rhits 0))
   (tooltip-mode -1)
   (scroll-bar-mode -1)
   (set-mouse-pixel-position (selected-frame) i 200)
   (while (car (setq position (cdr (mouse-pixel-position))))
     (let ((coordinates (coordinates-in-window-p position window-on-left t)))
       (when (eq coordinates 'vertical-line)
	(setq lhits (1+ lhits))))
     (let ((coordinates (coordinates-in-window-p position window-on-right t)))
       (when (eq coordinates 'vertical-line)
	(setq rhits (1+ rhits))))
     (sit-for 0.001)
     (set-mouse-pixel-position
      (selected-frame) (setq i (1- i)) 200))
   (cons lhits rhits))

gets me the same results.  What do you get?  You might have to change
the initial values of `i' to "be in the frame" accordingly.

martin

[-- Attachment #2: coordinates-in-window-p.diff --]
[-- Type: text/plain, Size: 1918 bytes --]

=== modified file 'src/window.c'
--- src/window.c	2014-02-21 08:02:05 +0000
+++ src/window.c	2014-02-21 18:16:00 +0000
@@ -1410,13 +1410,15 @@


 DEFUN ("coordinates-in-window-p", Fcoordinates_in_window_p,
-       Scoordinates_in_window_p, 2, 2, 0,
+       Scoordinates_in_window_p, 2, 3, 0,
        doc: /* Return non-nil if COORDINATES are in WINDOW.
 WINDOW must be a live window and defaults to the selected one.
 COORDINATES is a cons of the form (X . Y), X and Y being distances
 measured in characters from the upper-left corner of the frame.
 \(0 . 0) denotes the character in the upper left corner of the
-frame.
+frame.  Third argument PIXELWISE non-nil means interpret coordinates
+pixelwise.
+
 If COORDINATES are in the text portion of WINDOW,
    the coordinates relative to the window are returned.
 If they are in the mode line of WINDOW, `mode-line' is returned.
@@ -1427,7 +1429,7 @@
   `vertical-line' is returned.
 If they are in the windows's left or right marginal areas, `left-margin'\n\
   or `right-margin' is returned.  */)
-  (register Lisp_Object coordinates, Lisp_Object window)
+  (register Lisp_Object coordinates, Lisp_Object window, Lisp_Object pixelwise)
 {
   struct window *w;
   struct frame *f;
@@ -1439,10 +1441,16 @@
   CHECK_CONS (coordinates);
   lx = Fcar (coordinates);
   ly = Fcdr (coordinates);
-  CHECK_NUMBER_OR_FLOAT (lx);
-  CHECK_NUMBER_OR_FLOAT (ly);
-  x = FRAME_PIXEL_X_FROM_CANON_X (f, lx) + FRAME_INTERNAL_BORDER_WIDTH (f);
-  y = FRAME_PIXEL_Y_FROM_CANON_Y (f, ly) + FRAME_INTERNAL_BORDER_WIDTH (f);
+  CHECK_NUMBER (lx);
+  CHECK_NUMBER (ly);
+  x = ((!NILP (pixelwise)
+    ? XINT (lx)
+    : FRAME_PIXEL_X_FROM_CANON_X (f, lx))
+       + FRAME_INTERNAL_BORDER_WIDTH (f));
+  y = ((!NILP (pixelwise)
+    ? XINT (ly)
+    : FRAME_PIXEL_Y_FROM_CANON_Y (f, ly))
+       + FRAME_INTERNAL_BORDER_WIDTH (f));

   switch (coordinates_in_window (w, x, y))
     {

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 14:53 -0400 on Friday 2014-02-21, martin rudalics wrote:

>> Regardless of where the vertical line is, it is now almost impossible to
>> get the <=> handle to appear at all when approaching the vertical line
>> from the left -- I get it once in about fifty attempts. When approaching
>> the vertical line from the right, the <=> handle appears normally (and
>> it now appears normally when the vertical line is all the way to the
>> left as well).
>
> If you can apply the patch I posted earlier (and I attach here again)

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.

> you could try the following snippet with emacs -Q:
>
> (let ((i 200)
>       (window-on-left (selected-window))
>       (window-on-right (split-window-right))
>       (lhits 0)
>       (rhits 0))
>   (tooltip-mode -1)
>   (scroll-bar-mode -1)
>   (set-mouse-pixel-position (selected-frame) i 200)
>   (while (car (setq position (cdr (mouse-pixel-position))))
>     (let ((coordinates (coordinates-in-window-p position window-on-left t)))
>       (when (eq coordinates 'vertical-line)
> 	(setq lhits (1+ lhits))))
>     (let ((coordinates (coordinates-in-window-p position window-on-right t)))
>       (when (eq coordinates 'vertical-line)
> 	(setq rhits (1+ rhits))))
>     (sit-for 0.001)
>     (set-mouse-pixel-position
>      (selected-frame) (setq i (1+ i)) 200))
>   (cons lhits rhits))
>
> 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).

> Evaluating
>
> (let ((i 600)
>       (window-on-left (selected-window))
>       (window-on-right (split-window-right))
>       (lhits 0)
>       (rhits 0))
>   (tooltip-mode -1)
>   (scroll-bar-mode -1)
>   (set-mouse-pixel-position (selected-frame) i 200)
>   (while (car (setq position (cdr (mouse-pixel-position))))
>     (let ((coordinates (coordinates-in-window-p position window-on-left t)))
>       (when (eq coordinates 'vertical-line)
> 	(setq lhits (1+ lhits))))
>     (let ((coordinates (coordinates-in-window-p position window-on-right t)))
>       (when (eq coordinates 'vertical-line)
> 	(setq rhits (1+ rhits))))
>     (sit-for 0.001)
>     (set-mouse-pixel-position
>      (selected-frame) (setq i (1- i)) 200))
>   (cons lhits rhits))
>
> gets me the same results.  What do you get?  You might have to change
> the initial values of `i' to "be in the frame" accordingly.

I get (6 . 0) (with initial i = 400).

Nevertheless, I can almost never get the <=> handle when I approach from
the left.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

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

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

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

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

martin

bug#16647: Imprecisions with window-resizing cursors

[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.

bug#16647: Imprecisions with window-resizing cursors

[E Sabof]

N. Jackson <nljlistbox2@gmail.com> writes:

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

Yes that's my "small" name, and a pleasant surprise.

I'm getting (9 . 0) from both snippets (9 being the frame-char-width). I haven't "read" them yet, maybe I'll find something reproducible.

I'm also getting the same results on openbox as I did on xmonad.

Evgeni

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

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > I'm getting (9 . 0) from both snippets (9 being the frame-char-width). I haven't "read" them yet, maybe I'll find something reproducible.
 >
 > I'm also getting the same results on openbox as I did on xmonad.

I'm beginning to suspect that something strange is going on somewhere
between Emacs and the input device.  Could you try playing a bit with
`mouse-autoselect-window'?  More precisely, how soon (in pixels) it
selects a window when you move the mouse into it from another one.

martin

bug#16647: Imprecisions with window-resizing cursors

[E Sabof]

martin rudalics <rudalics@gmx.at> writes:

> I'm beginning to suspect that something strange is going on somewhere
> between Emacs and the input device.  Could you try playing a bit with
> `mouse-autoselect-window'?  More precisely, how soon (in pixels) it
> selects a window when you move the mouse into it from another one.

Everything works as it should, as far as I can tell. Both horizontally and vertically.

Evgeni

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 14:44 -0400 on Saturday 2014-02-22, martin rudalics wrote:

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

Does it not make a difference for you? Perhaps that's something worth
understanding?

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

Yes. Indeed. I dug out two different real mice and also plugged in my
23" desktop monitor so I can see the pixels.

The behaviour is the same as I reported with my trackpad and laptop
display.

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

Haha. Well to check out the behaviour of images in Emacs, after my
cursor keys didn't work, I admit I tried to make the image scroll with
the trackpad and the scrollbars, so maybe I'm not completely consistent
in my mouse abstinence. Although, in four years of using Emacs every
day, I never noticed that there was no horizontal scroll bar! And I use
the thumb on the vertical scroll bar to tell me how far down the
document I am.

N.

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 15:07 -0400 on Saturday 2014-02-22, E. Sabof wrote:

> martin rudalics <rudalics@gmx.at> writes:
>
>> I'm beginning to suspect that something strange is going on somewhere
>> between Emacs and the input device.  Could you try playing a bit with
>> `mouse-autoselect-window'?  More precisely, how soon (in pixels) it
>> selects a window when you move the mouse into it from another one.
>
> Everything works as it should, as far as I can tell. Both horizontally and vertically.
>
> Evgeni

With mouse-autoselect-window set to t, I also see everything working as
I expect it should (with GTK+ Version 3.8.8 as before). (But note the
interesting "however" in the last paragraph.)

    emacs -Q
    M-: (setq mouse-autoselect-window t) RET
    M-: (setq scroll-bar-mode -1) RET
    M-x (split-window-right) RET

Moving the mouse from the right, into the left window, the left window
is selected immediately I cross the vertical line and the mouse cursor
changes to the <=> at the same time.

Moving the mouse from the left, into the right window, the right window
is selected immediately I cross the vertical line. Mostly the mouse cursor
does not change though (as previously reported).

    emacs -Q
    M-: (setq mouse-autoselect-window t) RET
    M-: (set-frame-parameter nil 'right-divider-width 24) RET
    M-x (split-window-right) RET

Moving the mouse from the right, towards the left window, the left
window is selected immediately I cross the right edge of the vertical
line and the mouse cursor changes to the <=> at the same time.

Moving the mouse from the left, towards the right window, the mouse
cursor changes to the <=> immediately I cross the left edge of the
vertical line. The right window is selected immediately the mouse cursor
crosses the right edge of the the vertical line. _However_, the mouse
cursor stays as a <=> for a few pixels more movement to the right, and
it is at this time that, if it is clicked, it doesn't do anything, as
per Evgeni's original bug.

N.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 >> I'm beginning to suspect that something strange is going on somewhere
 >> between Emacs and the input device.  Could you try playing a bit with
 >> `mouse-autoselect-window'?  More precisely, how soon (in pixels) it
 >> selects a window when you move the mouse into it from another one.
 >
 > Everything works as it should, as far as I can tell. Both horizontally and vertically.

Two more things: What happens when you turn off tooltip-mode?

And please try (again) with these

(set-frame-parameter nil 'right-divider-width 10)
(set-frame-parameter nil 'bottom-divider-width 10)

and tell me whether and where/how long the <=> and

^
|
v

cursor shapes appear.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > Moving the mouse from the left, towards the right window, the mouse
 > cursor changes to the <=> immediately I cross the left edge of the
 > vertical line. The right window is selected immediately the mouse cursor
 > crosses the right edge of the the vertical line. _However_, the mouse
 > cursor stays as a <=> for a few pixels more movement to the right, and
 > it is at this time that, if it is clicked, it doesn't do anything, as
 > per Evgeni's original bug.

Hmmm...  It's the most concrete description of the problem I read so far
but it still doesn't help me explaining it :-(

How does this behave when you do

(set-frame-parameter nil 'bottom-divider-width 10)

and move from an upper to the lower window and vice-versa?

martin

bug#16647: Imprecisions with window-resizing cursors

[E Sabof]

martin rudalics <rudalics@gmx.at> writes:

> Two more things: What happens when you turn off tooltip-mode?

No change. Also the timing of the messages in the echo area is consistent with the cursor misbehaviour.

> And please try (again) with these
>
> (set-frame-parameter nil 'right-divider-width 10)
> (set-frame-parameter nil 'bottom-divider-width 10)
>
> and tell me whether and where/how long the <=> and
>
> ^
> |
> v
>
> cursor shapes appear.

This also makes no difference. The cursor changes as I enter the right divider, and fails to change when I enter the left fringe of the next window.

The cursor always changed when moving from top to bottom, half-way through the mode-line. When moving from bottom to top, everything works, like it used to.

It might be interesting to note, that if I

(setq mode-line-format nil)

, and move from top to bottom, the cursor change is consistently too late, or not happening at all, depending on the position of the bottom divider.

To me it looks like some code expects a full "character" movement, before it registers a change in location.

I've also modified the elisp snippet you've sent to use a timer instead of a loop (otherwise the cursor wouldn't refresh). I still got (9 . 0), even in cases with delayed transformation.

Evgeni

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 06:53 -0400 on Sunday 2014-02-23, martin rudalics wrote:

>> Moving the mouse from the left, towards the right window, the mouse
>> cursor changes to the <=> immediately I cross the left edge of the
>> vertical line. The right window is selected immediately the mouse cursor
>> crosses the right edge of the the vertical line. _However_, the mouse
>> cursor stays as a <=> for a few pixels more movement to the right, and
>> it is at this time that, if it is clicked, it doesn't do anything, as
>> per Evgeni's original bug.
>
> Hmmm...  It's the most concrete description of the problem I read so far
> but it still doesn't help me explaining it :-(
>
> How does this behave when you do
>
> (set-frame-parameter nil 'bottom-divider-width 10)
>
> and move from an upper to the lower window and vice-versa?
>
> martin

Badly.

First impressions: Before splitting the window horizontally (with the
backwardsly-named split-window-vertically), I notice that I get the
changed mouse cursor indicating that I can resize the window whenever I
cross the mode line / bottom divider, but, in fact, I am only able to
use it (to increase the size of the minibuffer) when the minibuffer is
active. When the minibuffer is inactive, I can't resize it, yet the
mouse cursor still changes indicating that I can. Presumably this is a
bug.

Okay, continuing:

    emacs -Q
    M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
    M-: (setq mouse-autoselect-window t)
    M-x split-window-vertically

Moving the mouse cursor upwards from the bottom window towards the top
window, as soon as I reach the bottom of the bottom divider the focus
changes to the upper window and the resizing mouse cursor appear. The
resizing cursor continues to be displayed until I cross the top of the
mode line into the top window. (Reasonable behaviour.)

Moving the mouse cursor downwards from the top window to the bottom
window, when I am about half way down the mode line the resizing cursor
appears and continues to be displayed until I cross the bottom of the
bottom divider into the bottom window, when the focus changes to the
lower window and the mouse cursor resumes its normal form. (Reasonable
behaviour.)

But:

    emacs -Q
    M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
    M-: (setq mouse-autoselect-window t)
    Drag the window divider up a few pixels (but less than one line)

Moving the mouse cursor upwards is as before. 

Moving the mouse cursor downwards is as before except that when it
crosses the bottom of the bottom divider into the bottom window, the
focus changes to the bottom window, _but_ the resizing mouse cursor
continues to be displayed well in to the bottom window, but will not
resize the window if clicked on there -- indeed clicking on it, I can
select text in the bottom window while it is still displayed as a
resizing cursor!

At 19:29 -0400 on Sunday 2014-02-23, E. Sabof wrote:

> To me it looks like some code expects a full "character" movement, before it registers a change in location.

I get a similar impression. Noticing that split-window-below is
documented to take only an argument that is an integral number of lines
(it does something when passed a decimal fraction but I can't figure out
what it is -- I thought it might then treat the argument as pixels but
that's not it), I wondered if the code assumes that the split can only
be an integral number of lines below the top of the window above, or
something, and fails to take into account a fractional position?

Regards,
N.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > To me it looks like some code expects a full "character" movement, before it registers a change in location.

Window manager size hints?  What happens when you set
`frame-resize-pixelwise' to t in your .emacs?

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > First impressions: Before splitting the window horizontally (with the
 > backwardsly-named split-window-vertically), I notice that I get the
 > changed mouse cursor indicating that I can resize the window whenever I
 > cross the mode line / bottom divider, but, in fact, I am only able to
 > use it (to increase the size of the minibuffer) when the minibuffer is
 > active. When the minibuffer is inactive, I can't resize it, yet the
 > mouse cursor still changes indicating that I can. Presumably this is a
 > bug.

I know.  I'll look into this eventually.

 > But:
 >
 >     emacs -Q
 >     M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
 >     M-: (setq mouse-autoselect-window t)
 >     Drag the window divider up a few pixels (but less than one line)
 >
 > Moving the mouse cursor upwards is as before.
 >
 > Moving the mouse cursor downwards is as before except that when it
 > crosses the bottom of the bottom divider into the bottom window, the
 > focus changes to the bottom window, _but_ the resizing mouse cursor
 > continues to be displayed well in to the bottom window, but will not
 > resize the window if clicked on there -- indeed clicking on it, I can
 > select text in the bottom window while it is still displayed as a
 > resizing cursor!
 >
 > At 19:29 -0400 on Sunday 2014-02-23, E. Sabof wrote:
 >
 >> To me it looks like some code expects a full "character" movement, before it registers a change in location.
 >
 > I get a similar impression. Noticing that split-window-below is
 > documented to take only an argument that is an integral number of lines
 > (it does something when passed a decimal fraction but I can't figure out
 > what it is -- I thought it might then treat the argument as pixels but
 > that's not it), I wondered if the code assumes that the split can only
 > be an integral number of lines below the top of the window above, or
 > something, and fails to take into account a fractional position?

Try with `frame-resize-pixelwise' non-nil in your .emacs.  Maybe it's
the size hints.

martin

bug#16647: Imprecisions with window-resizing cursors

[E Sabof]

martin rudalics <rudalics@gmx.at> writes:

> Window manager size hints?  What happens when you set
> `frame-resize-pixelwise' to t in your .emacs?

Changing frame-resize-pixelwise didn't have an effect. However, everything seems to work fine after (setq window-resize-pixelwise t).

Evgeni

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 03:40 -0400 on Monday 2014-02-24, martin rudalics wrote:

> Try with `frame-resize-pixelwise' non-nil in your .emacs.  Maybe it's
> the size hints.

At 09:00 -0400 on Monday 2014-02-24, E. Sabof wrote:

> Changing frame-resize-pixelwise didn't have an effect. However, everything seems to work fine after (setq window-resize-pixelwise t).

I see the same as Evgeni here on GTK+ Version 3.8.8:

    emacs -Q
    M-: (setq frame-resize-pixelwise t) RET
    M-x make-frame-command RET
    Switch to new frame
    M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
    M-x split-window-below RET

As before, the bug is not observed.

    Drag the window divider up a few pixels (but less than one line)

As before, the bug is observed.

But with

    emacs -Q
    M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
    M-x split-window-below RET
    Drag the window divider up a few pixels (but less than one line)
    Observe bug
    M-: (setq window-resize-pixelwise t)

The bug is no longer observed. Note that I didn't move the divider after
setting window-resize-pixelwise, the bug was immediately no longer
manifest.

N.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > Changing frame-resize-pixelwise didn't have an effect. However, everything seems to work fine after (setq window-resize-pixelwise t).

I think you found it.  Just to make sure - xdisp.c has this code:

   if (window_resize_pixelwise)
     {
       width = height = 1;
       goto virtual_glyph;
     }

Can you please comment it out and try once more?  In that case setting
`window-resize-pixelwise' to t should not help any more.

Thanks, martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > But with
 >
 >     emacs -Q
 >     M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
 >     M-x split-window-below RET
 >     Drag the window divider up a few pixels (but less than one line)
 >     Observe bug
 >     M-: (setq window-resize-pixelwise t)
 >
 > The bug is no longer observed. Note that I didn't move the divider after
 > setting window-resize-pixelwise, the bug was immediately no longer
 > manifest.

OK.  Can you try the same I asked Evgeni?  In xdisp.c remove this code

   if (window_resize_pixelwise)
     {
       width = height = 1;
       goto virtual_glyph;
     }

and check whether setting `window-resize-pixelwise' to t still changes
the behavior.  The expected answer is "no".

Thanks, martin

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 14:12 -0400 on Monday 2014-02-24, martin rudalics wrote:

>> But with
>>
>>     emacs -Q
>>     M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
>>     M-x split-window-below RET
>>     Drag the window divider up a few pixels (but less than one line)
>>     Observe bug
>>     M-: (setq window-resize-pixelwise t)
>>
>> The bug is no longer observed. Note that I didn't move the divider after
>> setting window-resize-pixelwise, the bug was immediately no longer
>> manifest.
>
> OK.  Can you try the same I asked Evgeni?  In xdisp.c remove this code
>
>   if (window_resize_pixelwise)
>     {
>       width = height = 1;
>       goto virtual_glyph;
>     }
>
> and check whether setting `window-resize-pixelwise' to t still changes
> the behavior.  The expected answer is "no".
>
> Thanks, martin

No, that's no good. Commenting out the body of that if statement results
in a seg fault when I approach the divider with the mouse cursor.

[nlj@moondust trunk]$ src/emacs -Q
Fatal error 11: Segmentation fault
Backtrace:
src/emacs[0x4f9d6b]
src/emacs[0x4e0e4e]
src/emacs[0x4f8d8e]
src/emacs[0x4f8f93]
/lib64/libpthread.so.0[0x359600ef90]
src/emacs[0x434ad3]
src/emacs[0x4b3cab]
src/emacs[0x4bbed3]
src/emacs[0x4bd378]
/lib64/libgdk-3.so.0[0x31f004e941]
/lib64/libgdk-3.so.0[0x31f004ebce]
/lib64/libgdk-3.so.0(gdk_display_get_event+0x68)[0x31f0023aa8]
/lib64/libgdk-3.so.0[0x31f004e9c2]
/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x146)[0x31ed047dc6]
/lib64/libglib-2.0.so.0[0x31ed048118]
/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x31ed0481bc]
/lib64/libgtk-3.so.0(gtk_main_iteration+0x15)[0x31f058a5b5]
src/emacs[0x4b5e52]
src/emacs[0x4e7a11]
src/emacs[0x4e7435]
src/emacs[0x537a22]
src/emacs[0x555df0]
src/emacs[0x556901]
src/emacs[0x4e622f]
src/emacs[0x4e6761]
src/emacs[0x4e7b18]
src/emacs[0x4eadd4]
src/emacs[0x58e726]
src/emacs[0x420b14]
src/emacs[0x4ebaf4]
src/emacs[0x4ecfb3]
src/emacs[0x4eebd0]
src/emacs[0x54f26e]
src/emacs[0x4e12de]
src/emacs[0x54f17b]
src/emacs[0x4e5737]
src/emacs[0x4e5a22]
src/emacs[0x417135]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x3595421b45]
src/emacs[0x417bf1]
Segmentation fault (core dumped)

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 >> OK.  Can you try the same I asked Evgeni?  In xdisp.c remove this code
 >>
 >>   if (window_resize_pixelwise)
 >>     {
 >>       width = height = 1;
 >>       goto virtual_glyph;
 >>     }
 >>
 >> and check whether setting `window-resize-pixelwise' to t still changes
 >> the behavior.  The expected answer is "no".
 >>
 >> Thanks, martin
 >
 > No, that's no good. Commenting out the body of that if statement results
 > in a seg fault when I approach the divider with the mouse cursor.

Sorry, that's all too obvious.  What I meant was to remove the entire

   if (window_resize_pixelwise)
     {
       width = height = 1;
       goto virtual_glyph;
     }
   else

stuff, that is from the "if" up to and including the following "else".

Anyway, I'm just about to be able to reproduce the bug here.  All I had
to do was to change the default font to some unusual value.

martin

bug#16647: Imprecisions with window-resizing cursors

[E Sabof]

martin rudalics <rudalics@gmx.at> writes:

>    if (window_resize_pixelwise)
>      {
>        width = height = 1;
>        goto virtual_glyph;
>      }
>
> Can you please comment it out and try once more?  In that case setting
> `window-resize-pixelwise' to t should not help any more.

Not sure if it still matters, but this no longer helps as you've predicted.

Evgeni

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 >>    if (window_resize_pixelwise)
 >>      {
 >>        width = height = 1;
 >>        goto virtual_glyph;
 >>      }
 >>
 >> Can you please comment it out and try once more?  In that case setting
 >> `window-resize-pixelwise' to t should not help any more.
 >
 > Not sure if it still matters, but this no longer helps as you've predicted.

In revision 116565 I hopefully fixed the problem with dividers.  The
problem with the vertical border remains and I might not be able to fix
it at all (at least not in a reasonable way).  If you are on X Windows
you can look into it as follows.  At the end of remember_mouse_glyph in
xdisp.c you can find this code:

   /* Visible feedback for debugging.  */
#if 0
#if HAVE_X_WINDOWS
   XDrawRectangle (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
		  f->output_data.x->normal_gc,
		  gx, gy, width, height);
#endif
#endif

You have to "comment it in" by removing the #if 0 and one #endif,
recompile, and with emacs -Q start moving the mouse.  It will start
filling your frame with rectangles around glyphs.  These are the mouse
glyph rectangles remember_mouse_glyph remembers and you will see them
drawn around your characters.  It might help to increase the default
font to see them better.  These rectangles are important because the
mouse tracking code decides that something "significant" has happened
only when the mouse ends up in another rectangle than the last time.

Now remove the scrollbars, split your frame via C-x 3 and watch the
rectangles fill up around the border between the windows (to redraw the
frame move the border).  You can notice two strange things when the size
of the left window is not an integral multiple of the default font:

(1) The <=> starts to appear only in a rectangle at the left of the
     border.  If that rectangle extends across the border, the <=> will
     continue to appear if you move the mouse to the right crossing the
     border.  As soon as the <=> is on the right of the border, you can't
     start dragging the border.

(2) The shape of the rectangle on the left of the border may vary.  If
     your right fringe is larger than the width for the default font, you
     will usually see a rectangle that is as wide as the fringe when you
     move into the fringe horizontally from the left.  If you move inside
     the fringe up and down (very near to the border but still on the
     left of it) you can observe less wide rectangles.

Confusing, isn't it?  A basic problem is that remember_mouse_glyph
doesn't know anything about windows or vertical borders.  It treats the
frame as one huge area and I haven't been able yet to clip mouse glyph
rectangles at window borders.  If anyone knows how to do that - and it
should be certainly doable and done, please tell me.  I'm too silly to
understand that because the value calculate for "gx + width" here always
remains less than the window's pixel width.

And if you set `window-resize-pixelwise' to t, you will immediately
notice that the rectangles reduce to single pixels.  So there are no
rectangles overlapping with window borders and the problem disappears
just as you discovered recently.

martin

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> Date: Wed, 26 Feb 2014 11:17:06 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: nljlistbox2@gmail.com, 16647@debbugs.gnu.org
> 
> (1) The <=> starts to appear only in a rectangle at the left of the
>      border.  If that rectangle extends across the border, the <=> will
>      continue to appear if you move the mouse to the right crossing the
>      border.  As soon as the <=> is on the right of the border, you can't
>      start dragging the border.
> 
> (2) The shape of the rectangle on the left of the border may vary.  If
>      your right fringe is larger than the width for the default font, you
>      will usually see a rectangle that is as wide as the fringe when you
>      move into the fringe horizontally from the left.  If you move inside
>      the fringe up and down (very near to the border but still on the
>      left of it) you can observe less wide rectangles.
> 
> Confusing, isn't it?  A basic problem is that remember_mouse_glyph
> doesn't know anything about windows or vertical borders.  It treats the
> frame as one huge area and I haven't been able yet to clip mouse glyph
> rectangles at window borders.  If anyone knows how to do that - and it
> should be certainly doable and done, please tell me.

I didn't read this thread attentively enough -- could you tell what
problem are you trying to solve?  If I know the answer,  I will be
happy to help.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

I now tried to address the following issues reported here:

 > On current trunk version, from emacs -Q
 >
 > 1)
 >
 > (progn
 >   (scroll-bar-mode -1)
 >   (split-window-right)
 >   )
 >
 > Slowly move the mouse from left to right across the vertical line splitting the windows. Once the mouse goes past the black line, it's still shown as <=>, although clicking-and-dragging on that area won't have any effect.

Confirmed.  The reason was that a mouse glyph could cross window
borders.  Should be fixed now.

 > 2)
 >
 > C-x 2
 >
 > Move the cursor from top to bottom, across the mode-line. Once the cursor enters the mode-line, it won't change to a "resize" cursor, although it's already possible to drag.

Confirmed (on a Gtk build).  The reason was that a mouse glyph from the
text area could extend into the mode line.  Should be fixed now.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

I now tried to address the following issues reported here:

 > On GTK3 with Emacs built from trunk on 2014-02-10, I do not see the
 > symptoms above exactly, but I do see another bug.
 >
 > With the recipe above:
 >
 > lag in appearance of <=> handle (probably okay?)
 > ================================================
 > As the mouse cursor crosses the vertical line there _is_ a distinct lag
 > in the appearance of the <=> handle, so that it _does_ appear to the
 > left or right of the line (depending upon which direction the mouse was
 > moving), unless the mouse movement is _extremely_ slow. I don't think
 > this behaviour is particularly unusual (although it seems part of a
 > distinct sluggishness in the windowing interface that wasn't there in
 > Emacs 24.3.1). The <=> handle never first appears further from the
 > vertical line than (roughly?) the width of the fringe. That is, the <=>
 > handle doesn't appear at all if one moves the mouse over the vertical
 > line too quickly, and this seems okay too.

I'm not all to sure about this.  But with a right fringe larger than the
default character width it was possible to not show the <=> until the
mouse was right over the vertical border.  This should be fixed now.
Please try again.

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

This might be due to the same reason as the issue described above.  The
mouse cursor won't appear when approaching the border from the left.
Please try again.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

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

Hopefully fixed now as mentioned in my previous post.  Please try again.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > First impressions: Before splitting the window horizontally (with the
 > backwardsly-named split-window-vertically), I notice that I get the
 > changed mouse cursor indicating that I can resize the window whenever I
 > cross the mode line / bottom divider, but, in fact, I am only able to
 > use it (to increase the size of the minibuffer) when the minibuffer is
 > active. When the minibuffer is inactive, I can't resize it, yet the
 > mouse cursor still changes indicating that I can. Presumably this is a
 > bug.

Should be fixed now.  Please look again.

 > But:
 >
 >     emacs -Q
 >     M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
 >     M-: (setq mouse-autoselect-window t)
 >     Drag the window divider up a few pixels (but less than one line)
 >
 > Moving the mouse cursor upwards is as before.
 >
 > Moving the mouse cursor downwards is as before except that when it
 > crosses the bottom of the bottom divider into the bottom window, the
 > focus changes to the bottom window, _but_ the resizing mouse cursor
 > continues to be displayed well in to the bottom window, but will not
 > resize the window if clicked on there -- indeed clicking on it, I can
 > select text in the bottom window while it is still displayed as a
 > resizing cursor!

Should work with my previous fix.  Please check again.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 >> And please try (again) with these
 >>
 >> (set-frame-parameter nil 'right-divider-width 10)
 >> (set-frame-parameter nil 'bottom-divider-width 10)
 >>
 >> and tell me whether and where/how long the <=> and
 >>
 >> ^
 >> |
 >> v
 >>
 >> cursor shapes appear.
 >
 > This also makes no difference. The cursor changes as I enter the right divider, and fails to change when I enter the left fringe of the next window.

Should work now.  Please try again.

 > The cursor always changed when moving from top to bottom, half-way through the mode-line. When moving from bottom to top, everything works, like it used to.
 >
 > It might be interesting to note, that if I
 >
 > (setq mode-line-format nil)
 >
 > , and move from top to bottom, the cursor change is consistently too late, or not happening at all, depending on the position of the bottom divider.

Should work as well, please try again.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

> Not sure if it still matters, but this no longer helps as you've predicted.

Thanks.  I'll remove this feature soon provided everything else works.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > I didn't read this thread attentively enough -- could you tell what
 > problem are you trying to solve?  If I know the answer,  I will be
 > happy to help.

Thanks for the offer.  The mouse glyph code was pretty broken (I suppose
already for quite some time) but I hopefully now fixed most issues.

If you are good at this - I need a function like XDrawRectangle with the
same signature but for debugging with the Windows API.  It would take me
at least an hour to write it.  Could you do that?

martin

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> Date: Thu, 27 Feb 2014 20:58:35 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 16647@debbugs.gnu.org
> 
> The reason was that a mouse glyph from the text area could extend
> into the mode line.

That's news to me.  Can you describe how it happens?

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> Date: Thu, 27 Feb 2014 21:00:22 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: esabof@gmail.com, nljlistbox2@gmail.com, 16647@debbugs.gnu.org
> 
> If you are good at this - I need a function like XDrawRectangle with the
> same signature but for debugging with the Windows API.  It would take me
> at least an hour to write it.  Could you do that?

I'm not good at all at that, but is w32_draw_rectangle what you want?

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 15:58 -0400 on Thursday 2014-02-27, martin rudalics wrote:

> I now tried to address the following issues reported here:

>> lag in appearance of <=> handle (probably okay?)

> I'm not all to sure about this.  But with a right fringe larger than the
> default character width it was possible to not show the <=> until the
> mouse was right over the vertical border.  This should be fixed now.
> Please try again.

Yes, I believe I only saw this sluggishness/lag the first day I was
testing.

>> 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.)
>
> This might be due to the same reason as the issue described above.  The
> mouse cursor won't appear when approaching the border from the left.
> Please try again.

I think I amended my description of this in later reports, wrt
s/left/right, but in any case the misbehaviour I was seeing is now fixed.

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 15:58 -0400 on Thursday 2014-02-27, martin rudalics wrote:

>> 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.)
>
> Hopefully fixed now as mentioned in my previous post.  Please try again.

Yes, fixed using today's trunk.

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 15:59 -0400 on Thursday 2014-02-27, martin rudalics wrote:

>> First impressions: Before splitting the window horizontally (with the
>> backwardsly-named split-window-vertically), I notice that I get the
>> changed mouse cursor indicating that I can resize the window whenever I
>> cross the mode line / bottom divider, but, in fact, I am only able to
>> use it (to increase the size of the minibuffer) when the minibuffer is
>> active. When the minibuffer is inactive, I can't resize it, yet the
>> mouse cursor still changes indicating that I can. Presumably this is a
>> bug.
>
> Should be fixed now.  Please look again.

No, this is the only misbehaviour I saw that is not fixed now. With

    GNU Emacs 24.3.50 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8) of
    2014-02-27 Repository revision: 116586
    rudalics@gmx.at-20140227192210-27ciko3o65i7w9pv 
    Windowing system distributor `Fedora Project', version 11.0.11404000

I still get the handle indicating I can resize the minibuffer, but I
cannot actually resize it unless it is active.

(But didn't you say you were going to defer fixing this for now?)

>> But:
>>
>>     emacs -Q
>>     M-: (set-frame-parameter nil 'bottom-divider-width 10) RET
>>     M-: (setq mouse-autoselect-window t)
>>     Drag the window divider up a few pixels (but less than one line)
>>
>> Moving the mouse cursor upwards is as before.
>>
>> Moving the mouse cursor downwards is as before except that when it
>> crosses the bottom of the bottom divider into the bottom window, the
>> focus changes to the bottom window, _but_ the resizing mouse cursor
>> continues to be displayed well in to the bottom window, but will not
>> resize the window if clicked on there -- indeed clicking on it, I can
>> select text in the bottom window while it is still displayed as a
>> resizing cursor!
>
> Should work with my previous fix.  Please check again.

Yes, seems fixed with today's trunk. :)

N.

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Thu, 27 Feb 2014 20:49:47 -0400
> Cc: 16647@debbugs.gnu.org, esabof@gmail.com
> 
> No, this is the only misbehaviour I saw that is not fixed now. With
> 
>     GNU Emacs 24.3.50 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8) of
>     2014-02-27 Repository revision: 116586
>     rudalics@gmx.at-20140227192210-27ciko3o65i7w9pv 
>     Windowing system distributor `Fedora Project', version 11.0.11404000
> 
> I still get the handle indicating I can resize the minibuffer, but I
> cannot actually resize it unless it is active.

And indeed you can't, and shouldn't.  This issue has nothing to do
with when the mouse pointer changes shape, it's an entirely different
issue.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 >>> First impressions: Before splitting the window horizontally (with the
 >>> backwardsly-named split-window-vertically), I notice that I get the
 >>> changed mouse cursor indicating that I can resize the window whenever I
 >>> cross the mode line / bottom divider, but, in fact, I am only able to
 >>> use it (to increase the size of the minibuffer) when the minibuffer is
 >>> active. When the minibuffer is inactive, I can't resize it, yet the
 >>> mouse cursor still changes indicating that I can. Presumably this is a
 >>> bug.
 >> Should be fixed now.  Please look again.
 >
 > No, this is the only misbehaviour I saw that is not fixed now. With
 >
 >     GNU Emacs 24.3.50 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8) of
 >     2014-02-27 Repository revision: 116586
 >     rudalics@gmx.at-20140227192210-27ciko3o65i7w9pv
 >     Windowing system distributor `Fedora Project', version 11.0.11404000
 >
 > I still get the handle indicating I can resize the minibuffer, but I
 > cannot actually resize it unless it is active.

I did fix the behavior for the bottom divider only.  The mode line
itself behaves differently.  I think I fixed that now as well.  Please
try again.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 >> The reason was that a mouse glyph from the text area could extend
 >> into the mode line.
 >
 > That's news to me.  Can you describe how it happens?

With a partially-visible line at the bottom of the window.  In that case
the mouse glyph covers the non-visible part of the character.  Moving
the mouse from top to bottom will not show the drag cursor on the
modeline as long as the cursor is within the invisible part of the mouse
glyph.  Now if only one or two pixels of that character are visible, you
will see the drag cursor only on the lowest two or four pixles of the
modeline.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > I'm not good at all at that, but is w32_draw_rectangle what you want?

Not really - the signature differs from that of XDrawRectangle :-(

martin

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> Date: Fri, 28 Feb 2014 12:00:02 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: evgkeni.sampelnikof@gmail.com, 16647@debbugs.gnu.org
> 
>  >> The reason was that a mouse glyph from the text area could extend
>  >> into the mode line.
>  >
>  > That's news to me.  Can you describe how it happens?
> 
> With a partially-visible line at the bottom of the window.

So you mean to say that the pixel values were not limited by the
maximum visible y pixel of the window, and now they are?

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> Date: Fri, 28 Feb 2014 12:00:12 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: esabof@gmail.com, nljlistbox2@gmail.com, 16647@debbugs.gnu.org
> 
>  > I'm not good at all at that, but is w32_draw_rectangle what you want?
> 
> Not really - the signature differs from that of XDrawRectangle :-(

Why do you need an exactly the same signature?  Can't a macro or a
wrapper function take care of the differences?  The code will have to
be separately compiled on each platform anyway.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > So you mean to say that the pixel values were not limited by the
 > maximum visible y pixel of the window, and now they are?

The problem was that a pixel value was not limited by the maximum y of
the text area of a window but was allowed to extend into the mode line
area of the window.  In addition, parts of the mode line and the entire
header line did not have any glyphs at all but that hardly affected the
cursor problem we are discussing here.

martin

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > Why do you need an exactly the same signature?  Can't a macro or a
 > wrapper function take care of the differences?  The code will have to
 > be separately compiled on each platform anyway.

Sure.  But for me writing a macro or a wrapper is tantamount to writing
that function from scratch.  Having it in the RIF would be optimal.

martin

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> Date: Fri, 28 Feb 2014 13:47:20 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: esabof@gmail.com, nljlistbox2@gmail.com, 16647@debbugs.gnu.org
> 
>  > Why do you need an exactly the same signature?  Can't a macro or a
>  > wrapper function take care of the differences?  The code will have to
>  > be separately compiled on each platform anyway.
> 
> Sure.  But for me writing a macro or a wrapper is tantamount to writing
> that function from scratch.  Having it in the RIF would be optimal.

RIF doesn't go to such low levels (and shouldn't, if you ask me).

bug#16647: OT: window-resizing cursor for minibuffer (Imprecisions with window-resizing cursors)

[N. Jackson]

At 06:59 -0400 on Friday 2014-02-28, martin rudalics wrote:

>>>> First impressions: Before splitting the window horizontally (with the
>>>> backwardsly-named split-window-vertically), I notice that I get the
>>>> changed mouse cursor indicating that I can resize the window whenever I
>>>> cross the mode line / bottom divider, but, in fact, I am only able to
>>>> use it (to increase the size of the minibuffer) when the minibuffer is
>>>> active. When the minibuffer is inactive, I can't resize it, yet the
>>>> mouse cursor still changes indicating that I can. Presumably this is a
>>>> bug.
>>> Should be fixed now.  Please look again.
>>
>> No, this is the only misbehaviour I saw that is not fixed now. With
>>
>>     GNU Emacs 24.3.50 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8) of
>>     2014-02-27 Repository revision: 116586
>>     rudalics@gmx.at-20140227192210-27ciko3o65i7w9pv
>>     Windowing system distributor `Fedora Project', version 11.0.11404000
>>
>> I still get the handle indicating I can resize the minibuffer, but I
>> cannot actually resize it unless it is active.
>
> I did fix the behavior for the bottom divider only.  The mode line
> itself behaves differently.  I think I fixed that now as well.  Please
> try again.
>
> martin

Hi Martin,

Yes, I rebuilt with this morning's trunk (Repository revision: 116611)
and this is now fixed. :)

Regards,
N.

bug#16647: OT: window-resizing cursor for minibuffer (Imprecisions with window-resizing cursors)

[N. Jackson]

At 02:47 -0400 on Friday 2014-02-28, Eli Zaretskii wrote:

>> From: nljlistbox2@gmail.com (N. Jackson)
>> 
>> No, this is the only misbehaviour I saw that is not fixed now. With
>> 
>>     GNU Emacs 24.3.50 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8) of
>>     2014-02-27 Repository revision: 116586
>>     rudalics@gmx.at-20140227192210-27ciko3o65i7w9pv 
>>     Windowing system distributor `Fedora Project', version 11.0.11404000
>> 
>> I still get the handle indicating I can resize the minibuffer, but I
>> cannot actually resize it unless it is active.
>
> And indeed you can't, and shouldn't.  This issue has nothing to do
> with when the mouse pointer changes shape, it's an entirely different
> issue.

That was certainly to do with when the mouse pointer changed shape. The
mouse pointer was changing shape, indicating that the minibuffer could
be resized, when in fact it could not be. 

I don't believe anyone ever suggested that that was the same issue as, or
even directly related to, the current bug.

I merely mentioned in passing when I noticed it while helping explore
the current bug, as it seemed worth bringing to Martin's attention, but
too minor to create yet another bug report for if he could fix it
immediately, Martin asked me to check that it was fixed. It turned out
that it wasn't (then), so I reported back with that information.

I'm not sure why you decided to object so adamantly to that.

N.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

 > RIF doesn't go to such low levels (and shouldn't, if you ask me).

Drawing rectangles could be useful in other cases as well, maybe even
from Elisp.  But maybe we should leave this privilege to the XWindow
people ;-)

martin

bug#16647: OT: window-resizing cursor for minibuffer (Imprecisions with window-resizing cursors)

[martin rudalics]

 > Yes, I rebuilt with this morning's trunk (Repository revision: 116611)
 > and this is now fixed. :)

Thanks for checking.  Anything that remains to be done in this area?

martin

bug#16647: Imprecisions with window-resizing cursors

[N. Jackson]

At 14:24 -0400 on Friday 2014-02-28, martin rudalics wrote:

>> Yes, I rebuilt with this morning's trunk (Repository revision: 116611)
>> and this is now fixed. :)
>
> Thanks for checking.  Anything that remains to be done in this area?

Not that I'm aware of. You seem to have fixed everything that I saw
not working.

bug#16647: OT: window-resizing cursor for minibuffer (Imprecisions with window-resizing cursors)

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: bug-gnu-emacs@gnu.org, martin rudalics <rudalics@gmx.at>, E Sabof <esabof@gmail.com>
> Date: Fri, 28 Feb 2014 13:30:42 -0400
> 
> I'm not sure why you decided to object so adamantly to that.

Because resizing the minibuffer has its own rules, different from
those of other buffers.  I tried what I thought you were doing and saw
expected behavior, given those special rules.

It is now clear that I misunderstood the description of the problem,
so I apologize for my misunderstanding.

bug#16647: Imprecisions with window-resizing cursors

[Eli Zaretskii]

> Date: Fri, 28 Feb 2014 19:23:48 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: esabof@gmail.com, nljlistbox2@gmail.com, 16647@debbugs.gnu.org
> 
>  > RIF doesn't go to such low levels (and shouldn't, if you ask me).
> 
> Drawing rectangles could be useful in other cases as well, maybe even
> from Elisp.  But maybe we should leave this privilege to the XWindow
> people ;-)

I meant to say that the line that separates users of RIF from their
implementations is on the xdisp.c and dispnew.c level, i.e. on the
level that implements high-level Emacs display functions.  Drawing a
rectangle is not one of them, because the display engine cares about
text, images, and cursors, not about rectangles and pixels.

bug#16647: Imprecisions with window-resizing cursors

[martin rudalics]

>> Thanks for checking.  Anything that remains to be done in this area?
>
> Not that I'm aware of. You seem to have fixed everything that I saw
> not working.

Closing this bug.

Thanks, martin