[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] New function org-speed-command-add for adding/modifying spee

From: Shankar Rao
Subject: Re: [PATCH] New function org-speed-command-add for adding/modifying speed commands
Date: Tue, 17 May 2022 15:01:45 +0200

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:

        '(("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

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?


On Tue, May 3, 2022 at 12:23 PM Ihor Radchenko <yantar92@gmail.com> wrote:
> Shankar Rao <shankar.rao@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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]