bug#38013: [PATCH] Rectangular region selection with mouse

[Mattias Engdegård-2]

This is a proposal to add mouse-selection of rectangular regions. It turns out to be useful; Emacs should come with the facility built-in.

The main problem is what to bind it to. The common modifiers (shift, control, meta) are already taken. Platforms have different "standard" modifiers: Option on macOS, Alt on Windows, Control in Gnome (?).

Assuming that the secondary selection is somewhat of an anachronism which is likely to be less used today than the rectangular one would be, the patch uses Meta as default modifier. Both secondary and rectangular mouse selection have defcustoms permitting easy change.

The defaults could be different, for example if secondary mouse selection turns out to be very popular.
There is no documentation yet.

[Drew Adams]

> This is a proposal to add mouse-selection of rectangular regions. It
> turns out to be useful; Emacs should come with the facility built-in.
>
> The main problem is what to bind it to. The common modifiers (shift,
> control, meta) are already taken. Platforms have different "standard"
> modifiers: Option on macOS, Alt on Windows, Control in Gnome (?).
>
> Assuming that the secondary selection is somewhat of an anachronism
> which is likely to be less used today than the rectangular one would
> be, the patch uses Meta as default modifier. Both secondary and
> rectangular mouse selection have defcustoms permitting easy change.
>
> The defaults could be different, for example if secondary mouse
> selection turns out to be very popular.
> There is no documentation yet.

FWIW -

1. I like the general idea of being able to use
the mouse to directly define a rectangular region.
_Good initiative_.

2. But I disagree completely that the secondary
selection is an anachronism.

IMO it is not used as much as it could (and should
and would) be used in Emacs only because it has no
_keyboard_ bindings, by default.

I use C-M-y to do all of this:

* yank the secondary                 (no pref arg)
* select the secondary as the region (pref arg = 0)
* move the secondary to the region   (pref arg > 0)
* swap the secondary and the region  (pref arg < 0)

The 3rd and 4th of those set the secondary with just
the keyboard - from the region.  Another way to set
it using just the keyboard is to use C-x C-M-SPC to
start it and C-x C-M-<return> to end it.

(And I use C-M-y during Isearch to yank the secondary
to the end of the search string.)

The secondary selection is different from the region.
Its advantage, and its disadvantage, is that it is
liberated from point - it need not even be currently
visible in a window.  It doesn't change just because
you move the cursor around.

The region has a ring, `kill-ring', to let you get
previous selections.  I do the same thing for the
secondary selection, as well - give it a ring.  And
if the previous command yanked the secondary then
M-y yank-pops the secondary ring (not the kill-ring),
to replace that yank with the previous secondary on
the ring.

https://www.emacswiki.org/emacs/SecondarySelection#second-sel.el

[Eli Zaretskii]

> From: Mattias Engdegård <[hidden email]>
> Date: Thu, 31 Oct 2019 22:55:26 +0100
>
> This is a proposal to add mouse-selection of rectangular regions. It turns out to be useful; Emacs should come with the facility built-in.

Could you please tell how to try and test this feature?  The patch
comes without any documentation, so it's hard to understand quickly
what to do to see this in action.

> The main problem is what to bind it to. The common modifiers (shift, control, meta) are already taken. Platforms have different "standard" modifiers: Option on macOS, Alt on Windows, Control in Gnome (?).
>
> Assuming that the secondary selection is somewhat of an anachronism which is likely to be less used today than the rectangular one would be, the patch uses Meta as default modifier. Both secondary and rectangular mouse selection have defcustoms permitting easy change.

I'd prefer not to step on another feature, if possible.  How about
defining a minor mode, and then using the usual mouse selection
gestures instead?  That would be more natural, IMO, and will not
require users to give up another feature.

Thanks.

[Mattias Engdegård-2]

1 nov. 2019 kl. 08.51 skrev Eli Zaretskii <[hidden email]>:

> Could you please tell how to try and test this feature?  The patch
> comes without any documentation, so it's hard to understand quickly
> what to do to see this in action.

With the default settings, click and drag (mouse button 1) with meta held to mark a rectangular region.
Sorry about the lack of documentation; it will be written once we agree on the design.

> I'd prefer not to step on another feature, if possible.  How about
> defining a minor mode, and then using the usual mouse selection
> gestures instead?  That would be more natural, IMO, and will not
> require users to give up another feature.

Very much agree that other features should be left alone, but in this case there seemed to be no really good unused binding.
A minor mode is less ideal: rectangular selection is something the user wants to be able to do on a whim, without having to plan ahead by activating a minor mode. It is also good to follow standard practice in other editors and terminal emulators

Competing mouse bindings are:

Meta: secondary selection
Shift: mouse-appearance-menu (mouse-save-then-kill for NS)
Control: mouse-buffer-menu

The secondary selection appeared weaker than the rest, in the sense that repurposing its binding would annoy fewer users than the alternatives. (Annoyed users can still regain the old behaviour by customisation.)

Other possibilities:

A. Unbind mouse-appearance-menu, mouse-save-then-kill or mouse-buffer-menu instead. The trade-offs are similar.
B. Combined modifiers (Shift-Meta etc). Less ergonomic; there may be platform restrictions.
C. Use a different mouse button. Diverges from other platforms; messy on Macs.
D. Less common modifiers (Super, Hyper). Many don't have them.
E. Follow the platform conventions. Not the Emacs tradition, and makes for more binding clashes.
F. Leaving rectangular selection unbound by default. This is tantamount to stating that it is less useful. Is it?

[Eli Zaretskii]

> From: Mattias Engdegård <[hidden email]>
> Date: Fri, 1 Nov 2019 12:53:44 +0100
> Cc: [hidden email]
>
> With the default settings, click and drag (mouse button 1) with meta held to mark a rectangular region.

Thanks, I will try.

> A minor mode is less ideal: rectangular selection is something the user wants to be able to do on a whim, without having to plan ahead by activating a minor mode. It is also good to follow standard practice in other editors and terminal emulators

And yet cua-rect.el defined a command to enter this mode.

I don't really buy the "on a whim" argument; I think the user always
knows in advance whether the next selection will or won't be
rectangular.  So I still think a minor mode is the best solution, if
something like C-M-mouse-1 is not portable enough.

[martin rudalics]

9> Competing mouse bindings are:
 >
 > Meta: secondary selection

The meta combinations are bound to the secondary selection in a very
elaborate fashion and should be left alone.

 > Shift: mouse-appearance-menu (mouse-save-then-kill for NS)
 > Control: mouse-buffer-menu

I have no idea why these are bound to down events in the first place.
I would reserve S-down-mouse-1 for extending an existing selection and
provide C-down-mouse-1 for rectangular selection.  Some programs allow
C-down-mouse-1 to provide non-contiguous selections which we then
could accommodate easily by checking initially whether a selection is
already active.

 > B. Combined modifiers (Shift-Meta etc). Less ergonomic; there may be platform restrictions.

I'd consider these as viable alternatives.

martin

[Eli Zaretskii]

> Date: Fri, 01 Nov 2019 15:17:07 +0200
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email]
>
> > From: Mattias Engdegård <[hidden email]>
> > Date: Fri, 1 Nov 2019 12:53:44 +0100
> > Cc: [hidden email]
> >
> > With the default settings, click and drag (mouse button 1) with meta held to mark a rectangular region.
>
> Thanks, I will try.

Tried it.  I see 2 problems:

 . an annoying 1-pixel horizontal movement when I just press
   M-mouse-1, but don't move it; this doesn't happen in a "normal"
   selection by dragging mouse-1
 . problems when dragging the mouse across a TAB -- you cannot select
   just a "part" of the TAB's 8-column white space (see cua-rect.el
   for how this can be done better)

In addition, it looks like making the rectangular selection is very
error-prone: about 40% of the attempts I get a non-rectangular
selection instead, and sometimes the selection "jumps" to the other
side, i.e. I drag the mouse to the right, but get the text from the
mouse to the _left_ selected, and the selection extends to the BOB.

Thanks.

[Mattias Engdegård-2]

1 nov. 2019 kl. 14.30 skrev Eli Zaretskii <[hidden email]>:

> . an annoying 1-pixel horizontal movement when I just press
>   M-mouse-1, but don't move it; this doesn't happen in a "normal"
>   selection by dragging mouse-1

It also happens with C-x SPC and is a result of creating a zero-width selection that still has to be visible somehow. Now mitigated, so that it goes away if you release the button without selecting anything.

> . problems when dragging the mouse across a TAB -- you cannot select
>   just a "part" of the TAB's 8-column white space (see cua-rect.el
>   for how this can be done better)

> In addition, it looks like making the rectangular selection is very
> error-prone: about 40% of the attempts I get a non-rectangular
> selection instead, and sometimes the selection "jumps" to the other
> side, i.e. I drag the mouse to the right, but get the text from the
> mouse to the _left_ selected, and the selection extends to the BOB.

Quite right! Now fixed so that the rectangle corners, including the starting and ending corner, are no longer limited to points in the text. They can now be beyond EOL or in the middle of a TAB. Thank you for making it better!

The customisable variables for rectangular and secondary selection are now sets of modifiers, so that combinations like (shift meta) can be used.

1 nov. 2019 kl. 14.23 skrev martin rudalics <[hidden email]>:

> The meta combinations are bound to the secondary selection in a very
> elaborate fashion and should be left alone.

Abstracting the modifiers for the secondary selection seemed straightforward to me. Did I miss anything?

> > Shift: mouse-appearance-menu (mouse-save-then-kill for NS)
> > Control: mouse-buffer-menu
>
> I have no idea why these are bound to down events in the first place.
> I would reserve S-down-mouse-1 for extending an existing selection and
> provide C-down-mouse-1 for rectangular selection.  Some programs allow
> C-down-mouse-1 to provide non-contiguous selections which we then
> could accommodate easily by checking initially whether a selection is
> already active.

It would be nice to avoid the automatic bias toward favouring existing bindings regardless of merit, but that requires a sound understanding of which operations are actually useful (or not). Picking some free multi-key modifier like shift-control would have nobody complain, but isn't necessarily optimal.

You seem to believe that mouse-buffer-menu and mouse-appearance-menu don't deserve their bindings. I'm neutral, but would be interested in what other people have to say about it.

[Drew Adams]

Sorry, but I don't see why you did any of what you
did that affects the secondary selection.  Why all
of that?  Why not just continue to provide the same
default mouse key bindings for it?

It's always been easy for a user to change those
default mouse key bindings.  How are things easier
for users after the proposed changes?

Searching your patch for "second", it seems that the
only changes affecting the secondary affect just the
(mouse) key bindings for it.  How is any of that
related to rectangular region selection?

I really don't see what has been gained by the
changes that affect the secondary selection.  Can
you please explain?  What's the aim - what's the
problem that this is trying to solve?

How about just removing all of the code in the
patch that deals with the secondary selection?
Is any of that needed, to provide mouse selection
of a rectangular region?

And I disagree with removing the longstanding
default mouse key bindings for the secondary.
You've done that in a roundabout way (defaulting
a new user option to nil), but you've done it,
AFAICT.

[BTW, there's no need to use '(); just () suffices.]

[martin rudalics]

 >> The meta combinations are bound to the secondary selection in a very
 >> elaborate fashion and should be left alone.
 >
 > Abstracting the modifiers for the secondary selection seemed
 > straightforward to me. Did I miss anything?

I meant that the code for working with the secondary selection has
been set up in a quite meticulous way so I would never mess with it
(including the modifiers it uses).

 > Picking some free multi-key modifier like shift-control would
 > have nobody complain, but isn't necessarily optimal.

I usually shift-control with my pinkie alone so I would consider it
optimal and use it for many key combinations all the time.

 > You seem to believe that mouse-buffer-menu and mouse-appearance-menu
 > don't deserve their bindings. I'm neutral, but would be interested
 > in what other people have to say about it.

These deserve their bindings though I would not pop up a menu from a
mouse-down event alone.  What I am obviously assuming is that the
rectangular region selection code is based on mouse-dragging from one
corner of the rectangle to the opposite one, so a mouse-drag is easily
distinguishable from a click for a pop-up-menu.  If this assumption is
wrong, my rebinding proposal is clearly void.

martin

[Mattias Engdegård-2]

4 nov. 2019 kl. 10.07 skrev martin rudalics <[hidden email]>:

> I meant that the code for working with the secondary selection has
> been set up in a quite meticulous way so I would never mess with it
> (including the modifiers it uses).

Not here to mess with it, but if the user prefers to free up the Meta modifier for something else but still have access to the secondary selection, it seems to be perfectly possible. The current patch applies the modifier in a consistent way on all related bindings.

Even better would be a unified binding interface that also takes care of clashes in an automated way.

(Drew, don't worry --- the bindings are placeholders so that people can try out the selection mechanism. The default bindings are yet to be determined.)

> I usually shift-control with my pinkie alone so I would consider it
> optimal and use it for many key combinations all the time.

Geometry of hands and keyboards varies; I find single-key modifiers easier (but not necessarily difficult) to use.

However, shift-control could be a reasonable default value, if we dare not alter anything else. Is there any reason to prefer one of {shift-control, shift-meta, control-meta} to the rest?

> These deserve their bindings though I would not pop up a menu from a
> mouse-down event alone.  What I am obviously assuming is that the
> rectangular region selection code is based on mouse-dragging from one
> corner of the rectangle to the opposite one, so a mouse-drag is easily
> distinguishable from a click for a pop-up-menu.  If this assumption is
> wrong, my rebinding proposal is clearly void.

Thanks for explaining. Unfortunately, region selection and menu pop-up do not seem to be compatible in that way --- at least I didn't manage to use the same modifier for both. Perhaps the events could be multiplexed somehow, but it seems to be on the hacky side.

[Drew Adams]

> (Drew, don't worry --- the bindings are placeholders so that people can
> try out the selection mechanism. The default bindings are yet to be
> determined.)

My latest question was why we would add all of that
stuff - options for choosing modifiers etc.  _Users
have control_ over key bindings now.  Just what's
the point of adding this other stuff?

And what exactly does that have to do with selecting
a rectangular region with the mouse?  Why should that
be mixed in with providing the possibility of using
a mouse to select a rectangular region?

And why provide any binding, by default, for doing
that?  The feature hasn't even been introduced to
users yet.  Why would we sacrifice a default binding
for it at this time?

[martin rudalics]

 > Thanks for explaining. Unfortunately, region selection and menu
 > pop-up do not seem to be compatible in that way --- at least I
 > didn't manage to use the same modifier for both. Perhaps the events
 > could be multiplexed somehow, but it seems to be on the hacky side.

If you bind it to the control key you should at least be able to pop
up the buffer menu yourself if the up event occurs at the same
position as the down event.

But here I can simply do

(global-set-key [C-down-mouse-1] 'mouse-drag-region)
(global-set-key [C-drag-mouse-1] 'mouse-set-region)
(global-set-key [C-mouse-1] 'mouse-buffer-menu)

and get both, normal mouse dragging and the buffer menu.  What more
would you need?

martin

[Mattias Engdegård-2]

4 nov. 2019 kl. 19.27 skrev martin rudalics <[hidden email]>:

> If you bind it to the control key you should at least be able to pop
> up the buffer menu yourself if the up event occurs at the same
> position as the down event.
>
> But here I can simply do
>
> (global-set-key [C-down-mouse-1] 'mouse-drag-region)
> (global-set-key [C-drag-mouse-1] 'mouse-set-region)
> (global-set-key [C-mouse-1] 'mouse-buffer-menu)
>
> and get both, normal mouse dragging and the buffer menu.  What more
> would you need?

The rectangle-mark code can perhaps be rewritten to work that way, but doesn't it force the pop-up menu to be used with click-release-select-click-release instead of the quicker click-select-release?

[martin rudalics]

 > The rectangle-mark code can perhaps be rewritten to work that way,

Any code based on mouse dragging should be written in such way that
the corresponding click event can be easily handed over to a separate
command.  That's what the drag- prefix is for.

 > but doesn't it force the pop-up menu to be used with
 > click-release-select-click-release instead of the quicker
 > click-select-release?

Yes and I think that the former is the correct and expected behavior.
I don't use the buffer menu but if I did I were much more annoyed by
the fact that when I abandon the selection by clicking somewhere else
I get an active region which I then have to click away in a further
step.

Note that even the Emacs manual itself confuses down-mouse events and
clicks as

   ‘C-mouse-1’
      This menu is for selecting a buffer.

      The MSB (“mouse select buffer”) global minor mode makes this menu
      smarter and more customizable.  *Note Buffer Menus::.

and

   It replaces the ‘mouse-buffer-menu’ commands, normally bound to
   ‘C-Down-mouse-1’

IMHO the rule should be that non-dragging commands are always bound to
clicks (including double and triple ones) and never to a down- event.
The menu bar might be an exception (Firefox even pops up an entry when
the mouse just hovers over it) but the various (non-)toolkits Emacs
uses for it apparently defeat a common unified behavior anway.

And personally, I'd reserve C-drag-mouse for marking arbitrary
non-contiguous text (like, for example, Firefox does) and use
C-S-drag-mouse for marking rectangular regions.

martin

[Mattias Engdegård-2]

5 nov. 2019 kl. 10.35 skrev martin rudalics <[hidden email]>:

> Any code based on mouse dragging should be written in such way that
> the corresponding click event can be easily handed over to a separate
> command.  That's what the drag- prefix is for.

All right, I re-wrote the patch to allow for independent use for X-mouse-N, but...

> > but doesn't it force the pop-up menu to be used with
> > click-release-select-click-release instead of the quicker
> > click-select-release?
>
> Yes and I think that the former is the correct and expected behavior.
> I don't use the buffer menu but if I did I were much more annoyed by
> the fact that when I abandon the selection by clicking somewhere else
> I get an active region which I then have to click away in a further
> step.

I don't think so; being able to select from a menu with a single dragging movement is not only more ergonomic, it's the expected behaviour of pop-up menus. mouse.el even contains a comment to that effect:

 ;; By binding these to down-going events, we let the user use the up-going
 ;; event to make the selection, saving a click.

You can try for yourself: with the patch applied, bind M-mouse-1 to a menu:

 (global-set-key [M-mouse-1] 'mouse-buffer-menu)

Now a single meta-click will open the menu, and meta-drag will mark a rectangle. This sort of multiplexing doesn't feel right, and affects both uses negatively.

For example, suppose you have marked a rectangle and change your mind. Intuitively, you will click somewhere to make the mark go away, using the same modifiers. But that doesn't work, because now you get a pop-up menu.

> IMHO the rule should be that non-dragging commands are always bound to
> clicks (including double and triple ones) and never to a down- event.

My patch now follows that rule, but it doesn't seem to solve any problem.

> And personally, I'd reserve C-drag-mouse for marking arbitrary
> non-contiguous text (like, for example, Firefox does) and use
> C-S-drag-mouse for marking rectangular regions.

Emacs's mouse bindings seem rather haphazard and organised mainly on the principle of first-come, enshrining a fair bit of historical baggage. For example, there are two different buffer menus (one for font and one for everything else). There is also the secondary selection, of which there seems to be much fewer actual users than people who just want to know how to disable it.

We could do worse than following some conventions that have become more or less universal, such as right-clicking (control-click on macOS) for a context menu.

That said, do you have any particular reason (precedence, ergonomics) for suggesting control-shift? I'd rather use meta and move secondary selection to shift-meta (say).

(As before, the attached patch uses meta but that is just a placeholder and should not be interpreted as the final word.)

[Drew Adams]

> All right, I re-wrote the patch to allow for
> independent use for X-mouse-N, but...

I have the same comments as before, FWIW.

  My latest question was why we would add all of that
  stuff - options for choosing modifiers etc.  _Users
  have control_ over key bindings now.  Just what's
  the point of adding this other stuff?

  And what exactly does that have to do with selecting
  a rectangular region with the mouse?  Why should that
  be mixed in with providing the possibility of using
  a mouse to select a rectangular region?

  And why provide any binding, by default, for doing
  that?  The feature hasn't even been introduced to
  users yet.  Why would we sacrifice a default binding
  for it at this time?

[Mattias Engdegård-2]

7 nov. 2019 kl. 18.53 skrev Drew Adams <[hidden email]>:

>  My latest question was why we would add all of that
>  stuff - options for choosing modifiers etc.  _Users
>  have control_ over key bindings now.  Just what's
>  the point of adding this other stuff?

That the least important part of the patch --- it was mainly to make it easier to change the bindings in a consistent way, since there are multiple bindings that go together.

>  And what exactly does that have to do with selecting
>  a rectangular region with the mouse?  Why should that
>  be mixed in with providing the possibility of using
>  a mouse to select a rectangular region?

The Meta modifier was already used by the secondary selection. Shift or control could have been used as well; I just picked the one that appeared to be used the least. It's not worth arguing about either, particular not at this stage; let's get the basics right first.

>  And why provide any binding, by default, for doing
>  that?  The feature hasn't even been introduced to
>  users yet.  Why would we sacrifice a default binding
>  for it at this time?

I'm not sure what you mean. Of course rectangular selection needs a binding. We just have to select one that is less bad than the alternatives.

[martin rudalics]

 > I don't think so; being able to select from a menu with a single
 > dragging movement is not only more ergonomic, it's the expected
 > behaviour of pop-up menus.

But by doing so it usurps all combinations of the control key and
mouse-1.  So we pay a high price for such a small convenience.  And
since I have never anywhere else seen a "context" menu pop up right
after a mouse press I would not consider it the expected behavior.

 > mouse.el even contains a comment to that
 > effect:
 >
 >   ;; By binding these to down-going events, we let the user use the up-going
 >   ;; event to make the selection, saving a click.

In all those 25 or more years it hasn't found its way into the Emacs
manual though.

 > You can try for yourself: with the patch applied, bind M-mouse-1 to a menu:
 >
 >   (global-set-key [M-mouse-1] 'mouse-buffer-menu)
 >
 > Now a single meta-click will open the menu, and meta-drag will mark
 > a rectangle. This sort of multiplexing doesn't feel right, and
 > affects both uses negatively.

But the same "multiplexing" already applies for operating the mouse
without any modifiers.  And I sometimes use it in a different context:
When I prematurely press the mouse button on a browser link, I can
always bow out by slightly moving the mouse, thus avoiding the
semantics of a click.

 > For example, suppose you have marked a rectangle and change your
 > mind. Intuitively, you will click somewhere to make the mark go
 > away, using the same modifiers. But that doesn't work, because now
 > you get a pop-up menu.

The menu should pop up iff the down and up events happen at the same
location.  Can we agree that this is hard to achieve after having
marked a rectangle?

 > Emacs's mouse bindings seem rather haphazard and organised mainly on
 > the principle of first-come, enshrining a fair bit of historical
 > baggage. For example, there are two different buffer menus (one for
 > font and one for everything else). There is also the secondary
 > selection, of which there seems to be much fewer actual users than
 > people who just want to know how to disable it.

Most applications I know do not even distinguish mouse and meta mouse
clicks so I doubt that many users will see this as a problem.

 > We could do worse than following some conventions that have become
 > more or less universal, such as right-clicking (control-click on
 > macOS) for a context menu.

For me mouse-3 is the preferred button to pop up a menu.  I never use
mouse-3 to extend the selection because I'm not used to switch mouse
buttons during one and the same action.

 > That said, do you have any particular reason (precedence,
 > ergonomics) for suggesting control-shift? I'd rather use meta and
 > move secondary selection to shift-meta (say).

I suggested control-shift because it's IMHO the most convenient
combination with two modifiers (at least on my past and present
keyboards).  And I wouldn't change default key bindings that have
existed for decades.  But since I never use the secondary selection I
cannot really defend it either.

martin

[Drew Adams]

> For me mouse-3 is the preferred button to pop up a menu.  I never use
> mouse-3 to extend the selection because I'm not used to switch mouse
> buttons during one and the same action.

(Replying just about this: mouse-3.)

Vanilla Emacs hard-wires the behavior to kill or
delete the region (depending on the value of
`mouse-drag-copy-region').  That action can be
handy, but it's sometimes inappropriate (e.g., in
a read-only buffer).  In any case, it is only one
possible action; there are often other actions on
the selected text that you might want to take.

See `mouse3.el'.  You can use mouse-3 for both
a contextual pop-up menu and for extending the
selection.

https://www.emacswiki.org/emacs/Mouse3