binding S-mouse-1

binding S-mouse-1

[Tak Kunihiro]

Keys <S-right> and <S-left> extend region.  I think that [S-mouse-1]
should behave similar by default.

I propose to bind mouse-appearance-menu to super instead of shift,
  (global-set-key [S-down-mouse-1] 'mouse-appearance-menu)
and bind following to let shift click to extend region on mouse.el.
  (global-set-key [S-down-mouse-1] 'ignore)
  (global-set-key [S-mouse-1] 'mouse-save-then-kill)


diff --git a/mouse.26.el b/mouse.el
index 9b6b169..fdca439 100755
--- a/mouse.26.el
+++ b/mouse.el
@@ -2046,7 +2046,7 @@ is copied instead of being cut."
 ;; event to make the selection, saving a click.
 (global-set-key [C-down-mouse-1] 'mouse-buffer-menu)
 (if (not (eq system-type 'ms-dos))
-    (global-set-key [S-down-mouse-1] 'mouse-appearance-menu))
+    (global-set-key [s-down-mouse-1] 'mouse-appearance-menu))
 ;; C-down-mouse-2 is bound in facemenu.el.
 (global-set-key [C-down-mouse-3]
   `(menu-item ,(purecopy "Menu Bar") ignore
@@ -2055,6 +2055,10 @@ is copied instead of being cut."
                   (mouse-menu-bar-map)
                 (mouse-menu-major-mode-map)))))
 
+;; Binding mouse-1 to extend region when `shift' is pressed.
+(global-set-key [S-down-mouse-1] 'ignore)
+(global-set-key [S-mouse-1] 'mouse-save-then-kill)
+
 ;; Binding mouse-1 to mouse-select-window when on mode-, header-, or
 ;; vertical-line prevents Emacs from signaling an error when the mouse
 ;; button is released after dragging these lines, on non-toolkit

Re: binding S-mouse-1

[Eli Zaretskii]

> Date: Sun, 28 May 2017 19:06:48 +0900 (JST)
> From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
> 
> Keys <S-right> and <S-left> extend region.  I think that [S-mouse-1]
> should behave similar by default.
> 
> I propose to bind mouse-appearance-menu to super instead of shift,
>   (global-set-key [S-down-mouse-1] 'mouse-appearance-menu)
> and bind following to let shift click to extend region on mouse.el.
>   (global-set-key [S-down-mouse-1] 'ignore)
>   (global-set-key [S-mouse-1] 'mouse-save-then-kill)

Isn't that backward-incompatible change in behavior?

FWIW, I use S-down-mouse-1 quite a lot, especially when testing
various display-related bug reports and questions.  Replacing it with
super, for which I have no key on my keyboard, would need both more
customizations and re-teaching my muscle memory.  All that just to
provide some kind of "consistency"?  I'm not sure it's a good enough
reason for changing such a veteran behavior.

Thanks.

Re: binding S-mouse-1

[Noam Postavsky]

On Sun, May 28, 2017 at 11:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 28 May 2017 19:06:48 +0900 (JST)
>> From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
>>
>> Keys <S-right> and <S-left> extend region.  I think that [S-mouse-1]
>> should behave similar by default.
>>
>> I propose to bind mouse-appearance-menu to super instead of shift,
>>   (global-set-key [S-down-mouse-1] 'mouse-appearance-menu)
>> and bind following to let shift click to extend region on mouse.el.
>>   (global-set-key [S-down-mouse-1] 'ignore)
>>   (global-set-key [S-mouse-1] 'mouse-save-then-kill)
>
> Isn't that backward-incompatible change in behavior?
>
> FWIW, I use S-down-mouse-1 quite a lot, especially when testing
> various display-related bug reports and questions.  Replacing it with
> super, for which I have no key on my keyboard, would need both more
> customizations and re-teaching my muscle memory.  All that just to
> provide some kind of "consistency"?  I'm not sure it's a good enough
> reason for changing such a veteran behavior.

This seems to be common behaviour across other applications (e.g.,
Firefox), so it could help with the muscle memory of newer users.
Perhaps we could enable it in cua-mode?

Moving mouse-appearance-menu to super doesn't work since we can't rely
on super being generally usable. Perhaps C-S- instead?

Re: binding S-mouse-1

[Tak Kunihiro]

>>> Keys <S-right> and <S-left> extend region.  I think that [S-mouse-1]
>>> should behave similar by default.
>>>
>>> I propose to bind mouse-appearance-menu to super instead of shift,
>>>   (global-set-key [S-down-mouse-1] 'mouse-appearance-menu)
>>> and bind following to let shift click to extend region on mouse.el.
>>>   (global-set-key [S-down-mouse-1] 'ignore)
>>>   (global-set-key [S-mouse-1] 'mouse-save-then-kill)
>>
>> Isn't that backward-incompatible change in behavior?
>>
>> FWIW, I use S-down-mouse-1 quite a lot, especially when testing
>> various display-related bug reports and questions.  Replacing it with
>> super, for which I have no key on my keyboard, would need both more
>> customizations and re-teaching my muscle memory.

I suppose you meant without customizations, you have to re-teach.  You
do not have to do both.

>> All that just to provide some kind of "consistency"?  I'm not sure
>> it's a good enough reason for changing such a veteran behavior.
>
> This seems to be common behaviour across other applications (e.g.,
> Firefox), so it could help with the muscle memory of newer users.
> Perhaps we could enable it in cua-mode?
> 
> Moving mouse-appearance-menu to super doesn't work since we can't rely
> on super being generally usable. Perhaps C-S- instead?

I think internal consistency between mouse-1 and S-mouse-1 also
matters as well as behavior of S-mouse-1 across applications.

Shift should modify operation by mouse-1.  I think `extend region' can
be regarded as modified set-point; however mouse-appearance-menu has
significant distance from set-point.

How about A or B?

A (global-set-key [C-S-down-mouse-1] 'mouse-appearance-menu)
A (global-set-key [S-down-mouse-1] 'ignore)
A (global-set-key [S-mouse-1] 'mouse-save-then-kill)

B (define-key cua--cua-keys-keymap [S-down-mouse-1] 'ignore)
B (define-key cua--cua-keys-keymap [S-mouse-1] 'mouse-save-then-kill)

Re: binding S-mouse-1

[Eli Zaretskii]

> Date: Mon, 29 May 2017 08:14:10 +0900 (JST)
> Cc: eliz@gnu.org, emacs-devel@gnu.org, tak.kunihiro@gmail.com
> From: Tak Kunihiro <tak.kunihiro@gmail.com>
> 
> >> FWIW, I use S-down-mouse-1 quite a lot, especially when testing
> >> various display-related bug reports and questions.  Replacing it with
> >> super, for which I have no key on my keyboard, would need both more
> >> customizations and re-teaching my muscle memory.
> 
> I suppose you meant without customizations, you have to re-teach.  You
> do not have to do both.

Yes, I do have to do both, because I will have to tell Emacs to use,
say, the left Windows key as super, and then learn to use that when I
need the menu which currently pops up by S-mouse-1.

> I think internal consistency between mouse-1 and S-mouse-1 also
> matters as well as behavior of S-mouse-1 across applications.

The current binding of S-mouse-1 was not taken out of thin air, it was
modeled on other applications as well, AFAIR.

> How about A or B?
> 
> A (global-set-key [C-S-down-mouse-1] 'mouse-appearance-menu)
> A (global-set-key [S-down-mouse-1] 'ignore)
> A (global-set-key [S-mouse-1] 'mouse-save-then-kill)
> 
> B (define-key cua--cua-keys-keymap [S-down-mouse-1] 'ignore)
> B (define-key cua--cua-keys-keymap [S-mouse-1] 'mouse-save-then-kill)

I don't use CUA, so my opinions about modifying its bindings don't
matter.  We should ask CUA users if they care.

But I don't think we should change the default behavior of S-mouse-1.

Re: binding S-mouse-1

[Tak Kunihiro]

>> I think internal consistency between mouse-1 and S-mouse-1 also
>> matters as well as behavior of S-mouse-1 across applications.
> 
> The current binding of S-mouse-1 was not taken out of thin air, it was
> modeled on other applications as well, AFAIR.

I suppose that you also infer consistency across applications.  If so,
targeting applications matter, I think.


>>> All that just to provide some kind of "consistency"?  I'm not sure
>>> it's a good enough reason for changing such a veteran behavior.

>> Shift should modify operation by mouse-1.  I think `extend region' can
>> be regarded as modified set-point; however mouse-appearance-menu has
>> significant distance from set-point.

> But I don't think we should change the default behavior of S-mouse-1.

How do you think about reason that I inferred, consistency within
Emacs?

Re: binding S-mouse-1

[Eli Zaretskii]

> Date: Tue, 30 May 2017 17:20:28 +0900 (JST)
> Cc: npostavs@users.sourceforge.net, emacs-devel@gnu.org, Yuri Khan
>  <yuri.v.khan@gmail.com>, tak.kunihiro@gmail.com
> From: Tak Kunihiro <tak.kunihiro@gmail.com>
> 
> >>> All that just to provide some kind of "consistency"?  I'm not sure
> >>> it's a good enough reason for changing such a veteran behavior.
> 
> >> Shift should modify operation by mouse-1.  I think `extend region' can
> >> be regarded as modified set-point; however mouse-appearance-menu has
> >> significant distance from set-point.
> 
> > But I don't think we should change the default behavior of S-mouse-1.
> 
> How do you think about reason that I inferred, consistency within
> Emacs?

Consistency has never been a reason strong enough to change a
long-standing behavior.

Re: binding S-mouse-1

[Yuri Khan]

On Mon, May 29, 2017 at 6:14 AM, Tak Kunihiro <tak.kunihiro@gmail.com> wrote:

> Shift should modify operation by mouse-1.  I think `extend region' can
> be regarded as modified set-point; however mouse-appearance-menu has
> significant distance from set-point.

+1.

Also, if you do that, you free the right mouse button for some context
menu. (It should probably contain the top seven items of the Edit
menu, and possibly more.)

Additionally, C-mouse-4 and C-mouse-5 could be bound to
text-scale-increase and text-scale-decrease.