From: Marco Wahl <email@example.com> To: Gustavo Barros <firstname.lastname@example.org> Cc: email@example.com Subject: Re: [Feature Request] More flexibility in org-speed-commands customization Date: Mon, 17 Aug 2020 11:40:49 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> (Gustavo Barros's message of "Mon, 03 Aug 2020 15:49:48 -0300") Hi Gustavo, > 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? Best regards, -- Marco
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 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
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 \ --email@example.com \ --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).