From: Marco Wahl <email@example.com>
To: Gustavo Barros <firstname.lastname@example.org>
Subject: Re: [Feature Request] More flexibility in org-speed-commands customization
Date: Mon, 17 Aug 2020 11:40:49 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (Gustavo Barros's message of "Mon, 03 Aug 2020 15:49:48 -0300")
> 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?
This sounds like a good idea to me.
Do you already have a respective patch?
next prev parent reply other threads:[~2020-08-17 9:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-03 18:49 [Feature Request] More flexibility in org-speed-commands customization Gustavo Barros
2020-08-17 9:40 ` Marco Wahl [this message]
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
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).