Re: binding S-mouse-1

[Tak Kunihiro <tak.kunihiro@gmail.com>]

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