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

[Mattias Engdegård]

26 nov. 2019 kl. 21.33 skrev Alan Third <alan@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!