Thank you for looking into this. As you recommended, I tried modifying ``org-speed-commands'' using the customize interface. While it did enable me to configure and organize ``org-speed-commands'' in just the way I would like, I found using the customize interface to be a bit cumbersome. Using the customize interface, for each command that I wished to add, I had to visually scan over the whole structure of ``org-speed-commands'' to see if the key for this command was already present in the list, and replace it with my command if it is, or prepend my command to the top of the list if not it was already present. Then after I saved the customization, it added the whole new value of ``org-speed-commands'' to the end of my init.el, making it more cluttered.
Alternatively using my ``org-speed-command-add'' requires me to add a single command to my init.el containing only my modifications: (org-speed-command-add '(("N" . ded-org-show-next-heading-tidily) ("P" . ded-org-show-previous-heading-tidily) ("h" . sbr-org-speed-insert-subheading) ("f" . org-forward-heading-or-item) ("b" . org-backward-heading-or-item) ("u" . org-up-heading-or-item) ("n" . org-next-heading-or-item) ("p" . org-prev-heading-or-item))) Using ``org-speed-command-add'', I don't have to be concerned with whether or not a given key is already present in ``org-speed-commands''. I agree that ``org-speed-command-add'' has undefined behavior when provided with only a descriptive headline as its first element. Would you be more amenable to this command if it either ignored or explicitly disallowed descriptive headline entries? Shankar On Tue, May 3, 2022 at 12:23 PM Ihor Radchenko <yanta...@gmail.com> wrote: > > Shankar Rao <shankar....@gmail.com> writes: > > > Over the weekend I thought about this issue of configuring > > `org-speed-commands' more easily, and I believe I have come up with a > > simpler solution that I have provided in the attached patch. > > > > This patch creates a new function `org-speed-command-add' that can be > > used to add new speed command shortcuts to `org-speed-commands', as > > well as modify existing shortcuts. This function takes as argument an > > alist in the same format as `org-speed-commands'. For each command for > > which the shortcut key is already present in `org-speed-commands', the > > old command is replaced with the new command at the same position. > > Commands with brand new shortcut keys are added to the user section of > > `org-speed-commands'. > > > > I believe this patch strikes a balance between power users, who can > > still directly customize `org-speed-commands', and non-experts, who > > may want to add/modify some speed commands without having to > > understand the structure and organization of `org-speed-commands'. > > I am not sure about usefulness of the proposed command. For non-power > users, we have cusomize interface. It should work just fine without a > need to introduce another function. > > Also, org-speed-command-add may behave strangely if the argument > contains descriptive headline like ("My command group title") as its > first element. > > Best, > Ihor