Issue with rectangle mouse selection

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Mattias Engdegård-2
28 nov. 2019 kl. 11.00 skrev Ergus <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Mattias Engdegård-2
> 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.)


Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Mattias Engdegård-2
28 nov. 2019 kl. 17.10 skrev Stefan Monnier <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Ergus
In reply to this post by Mattias Engdegård-2
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.



Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Mattias Engdegård-2
28 nov. 2019 kl. 18.11 skrev Ergus <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Ergus
On Fri, Nov 29, 2019 at 02:18:07PM +0100, Mattias Engdeg�rd wrote:

>28 nov. 2019 kl. 18.11 skrev Ergus <[hidden email]>:
>
>> 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.

photo_2019-11-29_15-35-37.jpg (237K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Mattias Engdegård-2
29 nov. 2019 kl. 15.39 skrev Ergus <[hidden email]>:

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


0001-Improved-mouse-rectangle-selection-robustness-bug-38.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Eli Zaretskii
> From: Mattias Engdegård <[hidden email]>
> Date: Sat, 30 Nov 2019 12:08:47 +0100
> Cc: Emacs developers <[hidden email]>
>
> > YES!!! this seems to work now. :)
>
> Perhaps the workaround should be mentioned in the docs for xterm-mouse-mode?

In PROBLEMS, I'd say.

Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Ergus
On Sat, Nov 30, 2019 at 02:22:36PM +0200, Eli Zaretskii wrote:

>> From: Mattias Engdeg�rd <[hidden email]>
>> Date: Sat, 30 Nov 2019 12:08:47 +0100
>> Cc: Emacs developers <[hidden email]>
>>
>> > 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.


Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Eli Zaretskii
> Date: Sat, 30 Nov 2019 15:51:19 +0100
> From: Ergus <[hidden email]>
> Cc: Mattias Engdegård <[hidden email]>,
> [hidden email]
>
> >> 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.)

Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Ergus
In reply to this post by Mattias Engdegård-2
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 <[hidden email]>:
>
>> 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).
>


Normal-selection.jpg (219K) Download Attachment
Rectangle-select-backward.jpg (226K) Download Attachment
Rectangle-select-forward.jpg (171K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Mattias Engdegård-2
30 nov. 2019 kl. 18.02 skrev Ergus <[hidden email]>:
>
> 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.


Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>>
>> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Mattias Engdegård-2
30 nov. 2019 kl. 22.28 skrev Ergus <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
>> 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..


Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Ergus
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 <[hidden email]>:
>>
>>>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


Rectangle_backward.jpg (152K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with rectangle mouse selection

Mattias Engdegård-2
3 dec. 2019 kl. 10.40 skrev Ergus <[hidden email]>:

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