[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Feature Request] More flexibility in org-speed-commands customizati
From: |
Marco Wahl |
Subject: |
Re: [Feature Request] More flexibility in org-speed-commands customization |
Date: |
Mon, 17 Aug 2020 11:40:49 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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