From: "Mattias Engdegård" <mattiase@acm.org>
To: Alan Third <alan@idiocy.org>
Cc: 38296@debbugs.gnu.org
Subject: bug#38296: Allow Option key to be modifier for non-char key and mouse events
Date: Tue, 26 Nov 2019 22:36:32 +0100 [thread overview]
Message-ID: <576F8E92-AC86-4CBA-9F59-99071A55F775@acm.org> (raw)
In-Reply-To: <20191126203324.GA7891@breton.holly.idiocy.org>
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!
next prev parent reply other threads:[~2019-11-26 21:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 10:55 bug#38296: Allow Option key to be modifier for non-char key and mouse events Mattias Engdegård
2019-11-21 18:39 ` Mattias Engdegård
2019-11-21 21:12 ` Alan Third
2019-11-22 20:01 ` Mattias Engdegård
2019-11-25 19:15 ` Mattias Engdegård
2019-11-26 20:33 ` Alan Third
2019-11-26 21:36 ` Mattias Engdegård [this message]
2019-11-26 22:03 ` Alan Third
2019-11-27 10:50 ` Mattias Engdegård
2019-11-27 4:51 ` Eli Zaretskii
2019-11-27 6:40 ` Richard Stallman
2019-11-27 10:45 ` Mattias Engdegård
2019-11-28 4:17 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=576F8E92-AC86-4CBA-9F59-99071A55F775@acm.org \
--to=mattiase@acm.org \
--cc=38296@debbugs.gnu.org \
--cc=alan@idiocy.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).