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

[Mattias Engdegård]

1 nov. 2019 kl. 14.30 skrev Eli Zaretskii <eliz@gnu.org>:

> . 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 <rudalics@gmx.at>:

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

0001-Mouse-rectangular-region-selection-bug-38013.patch
Description: Binary data