Issue with rectangle mouse selection

Issue with rectangle mouse selection

[Ergus]

Hi:

Trying the just new added rectangular mouse selection first, I'll say:
this is a very nice feature, very very thanks for it Mattias.

On the other hand:

  I see that it has some issues. Maybe this will need a bug report, but
as it has been just added, probably a BR is not needed yet.

1) In tui interface the rectangle region is not highlighted during the
mouse movement, just when the mouse button is released.

2) In gui the rectangle limit and the cursor position are in different
positions. This is more evident when using tabs indentation or crossing
empty lines.

Best
Ergus

Re: Issue with rectangle mouse selection

[Mattias Engdegård]

28 nov. 2019 kl. 11.00 skrev Ergus <spacibba@aol.com>:

> Trying the just new added rectangular mouse selection first, I'll say:
> this is a very nice feature, very very thanks for it Mattias.

Thanks for trying it, and for reporting your findings!

> 1) In tui interface the rectangle region is not highlighted during the
> mouse movement, just when the mouse button is released.

That's odd --- it seems to work with some terminals (after enabling xterm-mouse-mode).
Terminal.app and Gnome Terminal are fine, but Xterm exhibits the behaviour you describe.
I'll investigate.

> 2) In gui the rectangle limit and the cursor position are in different
> positions. This is more evident when using tabs indentation or crossing
> empty lines.

That's a behaviour inherited from the cursor-based rectangle marking (C-x SPC), which is the underlying mechanism. Ordinary linear region selection actually works the same way: the region includes the starting point but excludes the cursor position.

The only difference is that with rectangular selection, the mouse tracks the rectangle corner, not the cursor. This was done partly to get better behaviour when selecting up to the right margin, and partly because it felt visually more pleasing. It also makes it easier to select 0-column wide rectangles, which are occasionally useful, whereas zero-sized linear regions are not.

However, because of how the our eye-hand coordination works, a small offset matters very little in practice: the hand will automatically move to set the desired selection from the immediate visual feedback without the user consciously thinking about it.

By the way, I'm still not quite happy with the standard binding (C-M-mouse-1); it was a weak compromise. If we could dislodge the squatters of the Meta, Control or Shift bindings, I'd much rather use one of those modifiers.

Re: Issue with rectangle mouse selection

[Mattias Engdegård]

> Terminal.app and Gnome Terminal are fine, but Xterm exhibits the behaviour you describe.

XTerm does indeed not report mouse movements when modifiers are used, so there is little Emacs can do about it.
This may be intended; the source (button.c) contains

    /*
     * We reserve shift modifier for cut/paste operations.  In principle we
     * can pass through control and meta modifiers, but in practice, the
     * popup menu uses control, and the window manager is likely to use meta,
     * so those events are not delivered to SendMousePosition.
     */

If this bothers you, perhaps you could ask the maintainer to reconsider; gnome-terminal manages, after all. (XTerm clearly needs more options. Just like Emacs.)

Re: Issue with rectangle mouse selection

[Stefan Monnier]

> If this bothers you, perhaps you could ask the maintainer to
> reconsider; gnome-terminal manages, after all.

To xterm's credit, gnome-terminal uses a menu-bar so it doesn't have to
solve the same problem (the problem being xterm's use of popup menus
bound to control+mouse-down).


        Stefan

Re: Issue with rectangle mouse selection

[Mattias Engdegård]

28 nov. 2019 kl. 17.10 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> To xterm's credit, gnome-terminal uses a menu-bar so it doesn't have to
> solve the same problem (the problem being xterm's use of popup menus
> bound to control+mouse-down).

True, but xterm doesn't send events for meta-mouse or control-meta-mouse either.
Nor for *-shift-mouse; shift is active for selection even in mouse tracking mode.

Re: Issue with rectangle mouse selection

[Ergus]

On Thu, Nov 28, 2019 at 03:36:46PM +0100, Mattias Engdeg�rd wrote:
>> Terminal.app and Gnome Terminal are fine, but Xterm exhibits the behaviour you describe.
>
>XTerm does indeed not report mouse movements when modifiers are used, so there is little Emacs can do about it.
>This may be intended; the source (button.c) contains
>
>    /*
>     * We reserve shift modifier for cut/paste operations.  In principle we
>     * can pass through control and meta modifiers, but in practice, the
>     * popup menu uses control, and the window manager is likely to use meta,
>     * so those events are not delivered to SendMousePosition.
>     */
>
>If this bothers you, perhaps you could ask the maintainer to reconsider; gnome-terminal manages, after all. (XTerm clearly needs more options. Just like Emacs.)
>
Oh that's a bad new as I actually use xterm because it is the most
compatible with everything else in emacs. I actually made a question in
the help mailing list before choosing xterm.

I made some tests and after reading the xterm documentation for mouse
tracking I can confirm that mouse movements with modifiers are not sent
at all with "\e[?1002h" (It is not sending any event, not just the
modifiers).

But they are actually sent with "\e[?1003h", so it is already supported
but just in a higher level (Any-event tracking) that emacs seems not to
enable..

So there is nothing to report to the xterm team in my opinion. Just that
we will need to make some changes in the xterm back-end if we want to
support these kinds of events.

Re: Issue with rectangle mouse selection

[Mattias Engdegård]

28 nov. 2019 kl. 18.11 skrev Ergus <spacibba@aol.com>:

> I made some tests and after reading the xterm documentation for mouse
> tracking I can confirm that mouse movements with modifiers are not sent
> at all with "\e[?1002h" (It is not sending any event, not just the
> modifiers).

Try setting the X resource

*VT100*translations: #override \n\
 <Btn1Motion>: select-extend()

Re: Issue with rectangle mouse selection

[Ergus]

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

On Fri, Nov 29, 2019 at 02:18:07PM +0100, Mattias Engdeg�rd wrote:
>28 nov. 2019 kl. 18.11 skrev Ergus <spacibba@aol.com>:
>
>> I made some tests and after reading the xterm documentation for mouse
>> tracking I can confirm that mouse movements with modifiers are not sent
>> at all with "\e[?1002h" (It is not sending any event, not just the
>> modifiers).
>
>Try setting the X resource
>
>*VT100*translations: #override \n\
> <Btn1Motion>: select-extend()
>
YES!!! this seems to work now. :)

So the only issue now is what I reported on yesterday about the distance
between rectangle border (point) and pointer in white spaces (or empty
lines). But it seems to be related with display-line-numbers-mode.

To reproduce:

emacs -Q

M-x global-display-line-numbers-mode
M-x xterm-mouse-mode

Then I see something like the attached picture (seed the distance
there). Could you please give it a look?

Again very thanks and sorry for bothering so much.

Ergus.

[-- Attachment #2: photo_2019-11-29_15-35-37.jpg --]
[-- Type: image/jpeg, Size: 177325 bytes --]

Re: Issue with rectangle mouse selection

[Mattias Engdegård]

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

29 nov. 2019 kl. 15.39 skrev Ergus <spacibba@aol.com>:

> YES!!! this seems to work now. :)

Perhaps the workaround should be mentioned in the docs for xterm-mouse-mode?

> So the only issue now is what I reported on yesterday about the distance
> between rectangle border (point) and pointer in white spaces (or empty
> lines). But it seems to be related with display-line-numbers-mode.

That's clearly wrong, thanks for spotting it. There were problems with side-by-side windows as well. In addition, the mouse tracking was sometimes one cell off.

Please try the attached patch.

I couldn't make up my mind whether to have the mouse track the cursor or the rectangle corner. Tracking the cursor mirrors the behaviour of plain (linear) text selection, but corner tracking works better up to the right margin.

You can set mouse--rectangle-track-cursor to select either behaviour; I'm not sure if it should be a defcustom, or what the default should be. Right now it's nil (tracks the corner).


[-- Attachment #2: 0001-Improved-mouse-rectangle-selection-robustness-bug-38.patch --]
[-- Type: application/octet-stream, Size: 3493 bytes --]

From 737a80aee81679b62e3b4505e7c670135a211bb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org>
Date: Sat, 30 Nov 2019 11:37:04 +0100
Subject: [PATCH] Improved mouse rectangle selection robustness (bug#38013)

Make the rectangular selection work better with
display-line-numbers-mode and side-by-side windows.
Also make the mouse track either the text cursor or the rectangle
corner in a consistent way.

* lisp/mouse.el (mouse--rectangle-track-cursor): Added constant.
(mouse-drag-region-rectangle): Take the line-number width into
account, and use window-relative columns.  Track either the cursor or
rectangle corner with more care.
---
 lisp/mouse.el | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/lisp/mouse.el b/lisp/mouse.el
index f076e90bd9..4aaf876252 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -1964,6 +1964,10 @@ secondary-selection-from-region
     (move-overlay mouse-secondary-overlay (region-beginning) (region-end))))
 
 \f
+(defconst mouse--rectangle-track-cursor nil
+  "Whether the mouse tracks the cursor when selecting a rectangle.
+If nil, the mouse tracks the rectangle corner instead.")
+
 (defun mouse-drag-region-rectangle (start-event)
   "Set the region to the rectangle that the mouse is dragged over.
 This must be bound to a button-down mouse event."
@@ -1980,6 +1984,7 @@ mouse-drag-region-rectangle
          (bottom (if (window-minibuffer-p start-window)
                      (nth 3 bounds)
                    (1- (nth 3 bounds))))
+         (extra-margin (round (line-number-display-width 'columns)))
          (dragged nil)
          (old-track-mouse track-mouse)
          (old-mouse-fine-grained-tracking mouse-fine-grained-tracking)
@@ -1988,8 +1993,9 @@ mouse-drag-region-rectangle
          (adjusted-col (lambda (col)
                          (if (eq (current-bidi-paragraph-direction)
                                  'right-to-left)
-                             (- (frame-text-cols) col -1)
-                           col)))
+                             (- (window-width) col extra-margin
+                                (if mouse--rectangle-track-cursor 1 -1))
+                           (- col extra-margin))))
          (map (make-sparse-keymap)))
     (define-key map [switch-frame] #'ignore)
     (define-key map [select-window] #'ignore)
@@ -2018,13 +2024,15 @@ mouse-drag-region-rectangle
                (hscroll (if (window-live-p window)
                             (window-hscroll window)
                           0))
-               (mouse-pos (mouse-position))
-               (mouse-col (+ (cadr mouse-pos) hscroll))
-               (mouse-row (cddr mouse-pos))
+               (mouse-row (cddr (mouse-position)))
+               (mouse-col (+ (car (posn-col-row posn)) hscroll
+                             (if mouse--rectangle-track-cursor 0 1)))
                (set-col (lambda ()
                           (if (or (eolp) (eq (following-char) ?\t))
                               (rectangle--col-pos
                                (funcall adjusted-col mouse-col) 'point)
+                            (unless mouse--rectangle-track-cursor
+                              (forward-char))
                             (rectangle--reset-point-crutches)))))
           (if (and (eq window start-window)
                    mouse-row
-- 
2.21.0 (Apple Git-122.2)

Re: Issue with rectangle mouse selection

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sat, 30 Nov 2019 12:08:47 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > YES!!! this seems to work now. :)
> 
> Perhaps the workaround should be mentioned in the docs for xterm-mouse-mode?

In PROBLEMS, I'd say.

Re: Issue with rectangle mouse selection

[Ergus]

On Sat, Nov 30, 2019 at 02:22:36PM +0200, Eli Zaretskii wrote:
>> From: Mattias Engdeg�rd <mattiase@acm.org>
>> Date: Sat, 30 Nov 2019 12:08:47 +0100
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>> > YES!!! this seems to work now. :)
>>
>> Perhaps the workaround should be mentioned in the docs for xterm-mouse-mode?
>
>In PROBLEMS, I'd say.
>
Hi Eli:

If we put it only in PROBLEMS it will be harder to find for the users
than in xterm-mouse-mode documentation. Do we have something like a FAQ?

This issue is tricky, so probably it should be mentioned in more than
one place.

Re: Issue with rectangle mouse selection

[Eli Zaretskii]

> Date: Sat, 30 Nov 2019 15:51:19 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Mattias Engdegård <mattiase@acm.org>,
> 	emacs-devel@gnu.org
> 
> >> Perhaps the workaround should be mentioned in the docs for xterm-mouse-mode?
> >
> >In PROBLEMS, I'd say.
> >
> Hi Eli:
> 
> If we put it only in PROBLEMS it will be harder to find for the users
> than in xterm-mouse-mode documentation. Do we have something like a FAQ?

We have a FAQ, but I think a better place is NEWS, since this is a new
feature.  (We should have it in PROBLEMS as well, I think.)

Re: Issue with rectangle mouse selection

[Ergus]

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

Hi Mattias:

I tried the patch and it seems to reduce notably the issue. There is
still a small distance between the cursor arrow and the point (the arrow
stays over the rectangle's last position and the point is just after
it). But at least now the distance is small and remains more or less
constant.

Is it possible to keep the mouse and the point in the same position
without breaking too many things? (like when selecting without the C-M)

There are 3 pictures attached:

Square selection forward, backward and normal selection. Just to show
the difference.


On Sat, Nov 30, 2019 at 12:08:47PM +0100, Mattias Engdeg�rd wrote:
>29 nov. 2019 kl. 15.39 skrev Ergus <spacibba@aol.com>:
>
>> YES!!! this seems to work now. :)
>
>Perhaps the workaround should be mentioned in the docs for xterm-mouse-mode?
>
>> So the only issue now is what I reported on yesterday about the distance
>> between rectangle border (point) and pointer in white spaces (or empty
>> lines). But it seems to be related with display-line-numbers-mode.
>
>That's clearly wrong, thanks for spotting it. There were problems with side-by-side windows as well. In addition, the mouse tracking was sometimes one cell off.
>
>Please try the attached patch.
>
>I couldn't make up my mind whether to have the mouse track the cursor or the rectangle corner. Tracking the cursor mirrors the behaviour of plain (linear) text selection, but corner tracking works better up to the right margin.
>
>You can set mouse--rectangle-track-cursor to select either behaviour; I'm not sure if it should be a defcustom, or what the default should be. Right now it's nil (tracks the corner).
>



[-- Attachment #2: Normal-selection.jpg --]
[-- Type: image/jpeg, Size: 164157 bytes --]

[-- Attachment #3: Rectangle-select-backward.jpg --]
[-- Type: image/jpeg, Size: 168954 bytes --]

[-- Attachment #4: Rectangle-select-forward.jpg --]
[-- Type: image/jpeg, Size: 128241 bytes --]

Re: Issue with rectangle mouse selection

[Mattias Engdegård]

30 nov. 2019 kl. 18.02 skrev Ergus <spacibba@aol.com>:
> 
> Hi Mattias:
> 
> I tried the patch and it seems to reduce notably the issue. There is
> still a small distance between the cursor arrow and the point (the arrow
> stays over the rectangle's last position and the point is just after
> it). But at least now the distance is small and remains more or less
> constant.

That's on purpose --- it's designed to track the rectangle corner, not the text cursor.
Try setting mouse--rectangle-track-cursor to t if you prefer it the other way around. If that is more what people expect, then that will be the standard behaviour.

Re: Issue with rectangle mouse selection

[Ergus]

On Sat, Nov 30, 2019 at 06:06:59PM +0100, Mattias Engdeg�rd wrote:
>30 nov. 2019 kl. 18.02 skrev Ergus <spacibba@aol.com>:
>>
>> Hi Mattias:
>>
>> I tried the patch and it seems to reduce notably the issue. There is
>> still a small distance between the cursor arrow and the point (the arrow
>> stays over the rectangle's last position and the point is just after
>> it). But at least now the distance is small and remains more or less
>> constant.
>
>That's on purpose --- it's designed to track the rectangle corner, not the text cursor.
>Try setting mouse--rectangle-track-cursor to t if you prefer it the other way around. If that is more what people expect, then that will be the standard behaviour.
>
Oh, ok then.

We need more opinions about but I think that actually the most familiar
behaviour is setting mouse--rectangle-track-cursor to t for most
users... but lets wait for other opinions/complains related.

On the other hand; when selecting backward the behaviour must be the
same independently of mouse--rectangle-track-cursor; as the cursor is
actually the rectangle corner in that situation right?

So it shouldn't be out of the rectangle (like in the picture before). Or
it should?

Re: Issue with rectangle mouse selection

[Mattias Engdegård]

30 nov. 2019 kl. 22.28 skrev Ergus <spacibba@aol.com>:

> We need more opinions about but I think that actually the most familiar
> behaviour is setting mouse--rectangle-track-cursor to t for most
> users... but lets wait for other opinions/complains related.

I pushed that patch (with mouse tracking the text cursor); it's probably good enough.

By the way, the xterm quirk has now been reported to the maintainer.

> On the other hand; when selecting backward the behaviour must be the
> same independently of mouse--rectangle-track-cursor; as the cursor is
> actually the rectangle corner in that situation right?

Then you wouldn't be able to select the leftmost column.

Re: Issue with rectangle mouse selection

[Ergus]

On Sat, Nov 30, 2019 at 10:47:01PM +0100, Mattias Engdeg�rd wrote:
>30 nov. 2019 kl. 22.28 skrev Ergus <spacibba@aol.com>:
>
>> We need more opinions about but I think that actually the most familiar
>> behaviour is setting mouse--rectangle-track-cursor to t for most
>> users... but lets wait for other opinions/complains related.
>
>I pushed that patch (with mouse tracking the text cursor); it's probably good enough.
>
>By the way, the xterm quirk has now been reported to the maintainer.
>
>> On the other hand; when selecting backward the behaviour must be the
>> same independently of mouse--rectangle-track-cursor; as the cursor is
>> actually the rectangle corner in that situation right?
>
>Then you wouldn't be able to select the leftmost column.
>
That's actually the problem. When mouse--rectangle-track-cursor is
nil I can't select the leftmost column when selecting backward..

Re: Issue with rectangle mouse selection

[Ergus]

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

On Sun, Dec 01, 2019 at 07:24:03AM +0100, Ergus wrote:
>On Sat, Nov 30, 2019 at 10:47:01PM +0100, Mattias Engdeg�rd wrote:
>>30 nov. 2019 kl. 22.28 skrev Ergus <spacibba@aol.com>:
>>
>>>We need more opinions about but I think that actually the most familiar
>>>behaviour is setting mouse--rectangle-track-cursor to t for most
>>>users... but lets wait for other opinions/complains related.
>>
>>I pushed that patch (with mouse tracking the text cursor); it's probably good enough.
>>
>>By the way, the xterm quirk has now been reported to the maintainer.
>>
>>>On the other hand; when selecting backward the behaviour must be the
>>>same independently of mouse--rectangle-track-cursor; as the cursor is
>>>actually the rectangle corner in that situation right?
>>
>>Then you wouldn't be able to select the leftmost column.
>>
>That's actually the problem. When mouse--rectangle-track-cursor is
>nil I can't select the leftmost column when selecting backward..
>
>
Hi Mattias:

After a couple of days trying the rectangles I think that there are not
more issue to report from my side.

EXCEPT the one described in my latest message for backward
selection. This must be corrected otherwise we will receive bugs reports
very soon because with (setq mouse--rectangle-track-cursor nil) it is
not possible to select the first column (picture attached).

So far, for backward selection the variable mouse--rectangle-track-cursor
shouldn't change behaviour (and it should be what we have now when
mouse--rectangle-track-cursor is non-nil).

Personally I don't find the variable very useful cause the actual
defaults are good enough for most of the cases. And removing the
variable can simplify code a bit... but that's your choice.

Best
Ergus


[-- Attachment #2: Rectangle_backward.jpg --]
[-- Type: image/jpeg, Size: 113932 bytes --]

Re: Issue with rectangle mouse selection

[Mattias Engdegård]

3 dec. 2019 kl. 10.40 skrev Ergus <spacibba@aol.com>:

> Personally I don't find the variable very useful cause the actual
> defaults are good enough for most of the cases. And removing the
> variable can simplify code a bit... but that's your choice.

We seem to have made the correct choice then. It is clear that that variable should not be user-tunable.
Thanks for testing!