GNU bug report logs - #38296
Allow Option key to be modifier for non-char key and mouse events

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38296 in the body.
You can then email your comments to 38296 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Allow Option key to be modifier for non-char key and mouse events
Date: Wed, 20 Nov 2019 11:55:04 +0100

[Message part 1 (text/plain, inline)]

Mac users, especially those of us with a non-US keyboard, need the Option keys for entering various characters, and thus set 'ns-alternate-modifier' to nil, or use 'ns-right-alternate-modifier' to employ only one of them for this purpose. However, this prevents use of that key as modifier for function keys (arrows, backspace etc) or mouse actions.

This patch adds the variable 'ns-alternate-modifier-char-entry' which, when non-nil, inhibits the Option key translation to Emacs modifiers for character keys but allows it for any other event. For example, setting

(setq ns-alternate-modifier 'super)
(setq ns-alternate-modifier-char-entry t)

makes Option act as Super with function keys and mouse clicks, but retains the standard macOS semantics for character entry (for example, Option + p = π).

[0001-Add-ns-alternate-modifier-char-entry.patch (application/octet-stream, attachment)]

Message #10 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: 38296 <at> debbugs.gnu.org
Cc: Alan Third <alan <at> idiocy.org>
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Thu, 21 Nov 2019 19:39:49 +0100

It was pointed out to me that it would be useful to set this behaviour individually for either Option key.
This can be accomplished in various ways. For example, ns-alternate-modifier-char-entry could be changed from a boolean into taking either of the values nil, left, right or both, indicating to which Option key it applies.
Or we could simply use two separate boolean variables. I'd appreciate advice from the NS maintainers about what practice is best.

Message #13 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Thu, 21 Nov 2019 21:12:07 +0000

On Thu, Nov 21, 2019 at 07:39:49PM +0100, Mattias Engdegård wrote:
> It was pointed out to me that it would be useful to set this
> behaviour individually for either Option key. This can be
> accomplished in various ways. For example,
> ns-alternate-modifier-char-entry could be changed from a boolean
> into taking either of the values nil, left, right or both,
> indicating to which Option key it applies. Or we could simply use
> two separate boolean variables. I'd appreciate advice from the NS
> maintainers about what practice is best.

I was thinking about this and although the patch looks good to me, I
don’t find the variable name very descriptive. Perhaps it would be
better to go with something like ns-alternate-modifier-function-only?

Also probably best to add an ns-option-... alias too.

Do you think this functionality will only be required for the
alt/option key or will there be a demand to add it for command too? In
my experience the characters available via command are rather more
obscure, but I’ve little experience with non‐UK keyboards.

Anyway, as to your question, I think I prefer the two variable
approach. It mirrors the existing modifier variables.

Thanks for working on this.
-- 
Alan Third

Message #16 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Fri, 22 Nov 2019 21:01:17 +0100

[Message part 1 (text/plain, inline)]

21 nov. 2019 kl. 22.12 skrev Alan Third <alan <at> idiocy.org>:

> I was thinking about this and although the patch looks good to me, I
> don’t find the variable name very descriptive. Perhaps it would be
> better to go with something like ns-alternate-modifier-function-only?

Right. I wasn't satisfied with the name either, and ended up with ns-{left,right}-alternate-for-char-entry, which seemed more to the point.

> Also probably best to add an ns-option-... alias too.

Done. At first I thought it was just for compatibility and thus superfluous, but you are right --- the keys have always been Option on Macs; Alternate (or Alt) are from NeXT.

> Do you think this functionality will only be required for the
> alt/option key or will there be a demand to add it for command too? In
> my experience the characters available via command are rather more
> obscure, but I’ve little experience with non‐UK keyboards.

I've never seen Command be used to select characters at all. Some elaborate input methods?

> Anyway, as to your question, I think I prefer the two variable
> approach. It mirrors the existing modifier variables.

Agreed. As noted above, I used symmetric variables for the left and right option keys, both booleans, instead of a special 'left' value.

Thanks for the review; new patch attached.

[0001-Add-ns-left-right-alternate-for-char-entry.patch (application/octet-stream, attachment)]

Message #19 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Mon, 25 Nov 2019 20:15:31 +0100

[Message part 1 (text/plain, inline)]

21 nov. 2019 kl. 22.12 skrev Alan Third <alan <at> idiocy.org>:

> Do you think this functionality will only be required for the
> alt/option key or will there be a demand to add it for command too? In
> my experience the characters available via command are rather more
> obscure, but I’ve little experience with non‐UK keyboards.

Looking at Mitsuharu Yamamoto's Mac port made me change my mind: it solves the problem by allowing the variables to have values on the form (:ordinary SYMBOL :function SYMBOL :mouse SYMBOL), defining each modifier key separately for ordinary keys, function keys and mouse events.

This is more flexible, and turned out to be rather simple to implement, so I think this is better than adding variables. I did it for all ns-KEY-modifier and ns-right-KEY-modifier variables (KEY being control, command, alternate and function), since it seemed silly not to. The relevant macOS-specific documentation was improved as well.

Doing so also reduces gratuitous incompatibility with the Mac port.

Here is the new patch. Maybe we can get it done before Eli branches off Emacs 27.

[0001-Fine-grained-NS-modifier-key-settings-bug-38296.patch (application/octet-stream, attachment)]

Message #22 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Tue, 26 Nov 2019 20:33:24 +0000

On Mon, Nov 25, 2019 at 08:15:31PM +0100, Mattias Engdegård wrote:
> 21 nov. 2019 kl. 22.12 skrev Alan Third <alan <at> idiocy.org>:
> 
> > Do you think this functionality will only be required for the
> > alt/option key or will there be a demand to add it for command too? In
> > my experience the characters available via command are rather more
> > obscure, but I’ve little experience with non‐UK keyboards.
> 
> Looking at Mitsuharu Yamamoto's Mac port made me change my mind: it
> solves the problem by allowing the variables to have values on the
> form (:ordinary SYMBOL :function SYMBOL :mouse SYMBOL), defining
> each modifier key separately for ordinary keys, function keys and
> mouse events.

I had wondered about doing something like this, but not as flexible.
Is this the exact interface used by the Mac port? I’m not keen on the
word ‘ordinary’, but there’s no use in us doing something different.

> This is more flexible, and turned out to be rather simple to
> implement, so I think this is better than adding variables. I did it
> for all ns-KEY-modifier and ns-right-KEY-modifier variables (KEY
> being control, command, alternate and function), since it seemed
> silly not to. The relevant macOS-specific documentation was improved
> as well.

Thanks, it looks good to me. I’ve got a few nitpicks re. the
documentation:

+The modifiers themselves can be customised;

I think that should be a colon at the end, not a semi‐colon, although
my grasp of semi‐colon use is tenuous at best.

+The value of each variable is either a symbol, describing the key for
+any purpose, or a list on the form
                         ^
                        of

+@key{Option} key in macOS is normally used for composing additional

I would remove the word ‘normally’. I think it’s redundant since we’re
already talking about ‘standard behaviour’.

Unless anyone else has objections I don’t see any reason not to push
this.
-- 
Alan Third

Message #25 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Tue, 26 Nov 2019 22:36:32 +0100

26 nov. 2019 kl. 21.33 skrev Alan Third <alan <at> idiocy.org>:

> I had wondered about doing something like this, but not as flexible.
> Is this the exact interface used by the Mac port? I’m not keen on the
> word ‘ordinary’, but there’s no use in us doing something different.

Yes, it's the exact interface, except that the Mac port also allows an optional :button property for emulating multi-button mice. I didn't bother including that, but nothing prevents adding it later on.

> Thanks, it looks good to me. I’ve got a few nitpicks re. the
> documentation:

Those are always welcome!

> +The modifiers themselves can be customised;
> 
> I think that should be a colon at the end, not a semi‐colon, although
> my grasp of semi‐colon use is tenuous at best.

A @pxref command immediately follows, so the entire sentence would come out as

  The modifiers themselves can be customised; see Mac / GNUstep Customization.

Wouldn't the semicolon be more appropriate there? It does not really precede an elaboration, just another main clause.
I'm no native English speaker, though.

> +The value of each variable is either a symbol, describing the key for
> +any purpose, or a list on the form
>                         ^
>                        of

I'm torn here. What about 'having' instead?

> +@key{Option} key in macOS is normally used for composing additional
> 
> I would remove the word ‘normally’. I think it’s redundant since we’re
> already talking about ‘standard behaviour’.

Yes, but the phrase is then conditional on the symbol actually being 'none'.
Perhaps replacing 'normally' with 'then' would do?

> Unless anyone else has objections I don’t see any reason not to push
> this.

Thank you very much for the review!

Message #28 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Tue, 26 Nov 2019 22:03:07 +0000

On Tue, Nov 26, 2019 at 10:36:32PM +0100, Mattias Engdegård wrote:
> 26 nov. 2019 kl. 21.33 skrev Alan Third <alan <at> idiocy.org>:
> 
> > I had wondered about doing something like this, but not as flexible.
> > Is this the exact interface used by the Mac port? I’m not keen on the
> > word ‘ordinary’, but there’s no use in us doing something different.
> 
> Yes, it's the exact interface, except that the Mac port also allows
> an optional :button property for emulating multi-button mice. I
> didn't bother including that, but nothing prevents adding it later
> on.

I’m happy with that then.

> > +The modifiers themselves can be customised;
> > 
> > I think that should be a colon at the end, not a semi‐colon, although
> > my grasp of semi‐colon use is tenuous at best.
> 
> A @pxref command immediately follows, so the entire sentence would come out as
> 
>   The modifiers themselves can be customised; see Mac / GNUstep Customization.
> 
> Wouldn't the semicolon be more appropriate there? It does not really precede an elaboration, just another main clause.
> I'm no native English speaker, though.

I’m always suspicious of semi-colons because there are two types of
English speakers: those who don’t know how they’re used and therefore
don’t use them, and those who don’t know how they’re used and
therefore use them everywhere. ;)

I’ve had a quick look through the Emacs documentation and I found at
least one other example of using the semi‐colon like this, so I’m
happy leaving it.

> > +The value of each variable is either a symbol, describing the key for
> > +any purpose, or a list on the form
> >                         ^
> >                        of
> 
> I'm torn here. What about 'having' instead?

Having works, but the phrase is ‘of the form’.

    https://en.wikipedia.org/wiki/Of_the_form

I actually just assumed it was a typo. :)

> > +@key{Option} key in macOS is normally used for composing additional
> > 
> > I would remove the word ‘normally’. I think it’s redundant since we’re
> > already talking about ‘standard behaviour’.
> 
> Yes, but the phrase is then conditional on the symbol actually being 'none'.
> Perhaps replacing 'normally' with 'then' would do?

Yes, sounds good.

Oh, and thank you for actually documenting this. It was on my todo
list for the Emacs 27 release.

-- 
Alan Third

Message #31 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: alan <at> idiocy.org, 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Wed, 27 Nov 2019 06:51:31 +0200

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Tue, 26 Nov 2019 22:36:32 +0100
> Cc: 38296 <at> debbugs.gnu.org
> 
>   The modifiers themselves can be customised; see Mac / GNUstep Customization.

Btw, "customised" is not the US English spelling; please fix before
pushing.

Message #34 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: alan <at> idiocy.org, 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Wed, 27 Nov 2019 01:40:49 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Looking at Mitsuharu Yamamoto's Mac port made me change my mind: it solves the problem by allowing the variables to have values on the form (:ordinary SYMBOL :function SYMBOL :mouse SYMBOL), defining each modifier key separately for ordinary keys, function keys and mouse events.

I'd like to understand what that feature does, but I can't tell from
that text.  Does it come with any documentation?  If so, coulod you
please show it?

Also, are you proposing we implement this for ALL platforms (that
would be clean and simple, in principle)?  Or just SOME platforms?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #37 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: alan <at> idiocy.org, 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Wed, 27 Nov 2019 11:45:46 +0100

27 nov. 2019 kl. 07.40 skrev Richard Stallman <rms <at> gnu.org>:

> I'd like to understand what that feature does, but I can't tell from
> that text.  Does it come with any documentation?  If so, coulod you
> please show it?

This text is part of the documentation of the mac-KEY-modifier variables in the Mac port:

---
The property list form can include the `:button' property for button
number mapping, which becomes active when the value of
`mac-emulate-three-button-mouse' is nil.  The `:button' property can
be either a positive integer specifying the destination of the primary
button only, or a list (VALUE-FOR-PRIMARY-BUTTON VALUE-FOR-MOUSE-2
VALUE-FOR-MOUSE-3 ...) of positive integers specifying the
destinations of multiple buttons in order.  Note that the secondary
button and the button 3 (usually the wheel button) correspond to
mouse-3 and mouse-2 respectively if the value of
`mac-wheel-button-is-mouse-2' is non-nil (default), and mouse-2 and
mouse-3 respectively otherwise.  If a button is mapped to the same
number as its source, then it behaves as if the button were not mapped
so the `:mouse' property becomes in effect instead.
---

> Also, are you proposing we implement this for ALL platforms (that
> would be clean and simple, in principle)?  Or just SOME platforms?

The variables generalised by the patch are specific to the NS port. Whether something like this would be useful for other platforms isn't anything I have contemplated, but it is not inconceivable --- it would make keys like AltGr free to use as modifiers for mouse gestures and non-character keys. (Like the Option key on Macs, the AltGr key is used for entering even plain ASCII characters such as $@[]{}|\ on many keyboards, making those keys essential for almost any task.)

Message #42 received at 38296-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 38296-done <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Wed, 27 Nov 2019 11:50:19 +0100

26 nov. 2019 kl. 23.03 skrev Alan Third <alan <at> idiocy.org>:

> Having works, but the phrase is ‘of the form’.

Right you are, 'of' it is then.


27 nov. 2019 kl. 05.51 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Btw, "customised" is not the US English spelling; please fix before
> pushing.

Thank you, fixed. I'm not used to writing in that dialect.

Pushed to master.

Message #45 received at 38296 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: alan <at> idiocy.org, 38296 <at> debbugs.gnu.org
Subject: Re: bug#38296: Allow Option key to be modifier for non-char key and
 mouse events
Date: Wed, 27 Nov 2019 23:17:01 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It sounds like this could be useful on all platforms -- so let's do it
that way.  Can people please work on extending it to all platforms,
rather than to NS alone?

I think it would be correct to change the variable names so that they don't
say "mac-".


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.