From: Gustavo Barros <gusbrs.2016@gmail.com>
To: emacs-orgmode@gnu.org
Subject: [Feature Request] More flexibility in org-speed-commands customization
Date: Mon, 03 Aug 2020 15:49:48 -0300 [thread overview]
Message-ID: <87v9hzzhrn.fsf@gmail.com> (raw)
Hi All,
Org's speed keys are a very interesting feature to which I've long been
attracted to. And indeed, I've flirted with it a number of times in the
past. But every time I do so, I end up stepping back, because I get
weary of fat fingering my documents. The whole set of speed keys is
more powerful than what I would wish. I'd love to have speed keys for
navigation and visibility, but I would also gladly refrain from these
"too handy" editing keys.
As things stand, the speed keys are defined by combining
`org-speed-commands-default', a defconst, and `org-speed-commands-user',
a defcustom. But the former already contains a large set of speed keys,
including some quite powerful editing ones. And it is thus hard to
remove these keys.
Of course, it is possible. We could shadow the same key in
`org-speed-commands-user' to do nothing. Or, though a defconst,
`org-speed-commands-default' can be redefined after loading Org. The
first is clumsy, and renders the `org-speed-command-help' buffer quite
confusing. The second feels wrong (because it is).
I don't know if there is a strong reason to hard-code the set of keys in
`org-speed-commands-default'. But, if there isn't, could you consider
(somehow) exposing the whole set of `org-speed-commands' to user
customization?
Best,
Gustavo.
next reply other threads:[~2020-08-03 18:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-03 18:49 Gustavo Barros [this message]
2020-08-17 9:40 ` [Feature Request] More flexibility in org-speed-commands customization Marco Wahl
2020-08-17 10:39 ` Gustavo Barros
2020-09-04 17:45 ` Bastien
2020-09-04 18:37 ` Gustavo Barros
2021-05-01 16:24 ` Bastien
2021-05-01 21:24 ` Gustavo Barros
2021-05-02 6:29 ` Bastien
2021-05-02 16:03 ` Gustavo Barros
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.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v9hzzhrn.fsf@gmail.com \
--to=gusbrs.2016@gmail.com \
--cc=emacs-orgmode@gnu.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/org-mode.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).