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. |
> 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 |
In reply to this post by Mattias Engdegård-2
> 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. |
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? |
> 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. |
In reply to this post by Mattias Engdegård-2
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 |
In reply to this post by 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. |
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. |
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.] |
In reply to this post by Mattias Engdegård-2
>> 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 |
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, 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? |
In reply to this post by Mattias Engdegård-2
> 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 |
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? |
> 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 |
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.) |
> 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? |
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. |
In reply to this post by Mattias Engdegård-2
> 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 |
> 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 |
Free forum by Nabble | Edit this page |