emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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 


             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:

  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 \


* 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).