From: Gustavo Barros <email@example.com> To: firstname.lastname@example.org Subject: [Feature Request] More flexibility in org-speed-commands customization Date: Mon, 03 Aug 2020 15:49:48 -0300 [thread overview] Message-ID: <email@example.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 ` 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [Feature Request] More flexibility in org-speed-commands customization' \ /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
Code repositories for project(s) associated with this 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).