emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Unintended consequences of removing org-speed-commands-user
@ 2021-11-24  9:36 Shankar Rao
  2021-11-28 12:15 ` dal-blazej
  2021-11-30 14:19 ` [PATCH] New function org-speed-command-add for adding/modifying speed commands Shankar Rao
  0 siblings, 2 replies; 7+ messages in thread
From: Shankar Rao @ 2021-11-24  9:36 UTC (permalink / raw)
  To: emacs-orgmode

Hello all,

I discovered that upgrading to 9.5 broke my configuration because the
variable `org-speed-commands-user' was removed. I read the thread
(https://list.orgmode.org/87v9hzzhrn.fsf@gmail.com/) where this change
was proposed and I completely agree that exposing the whole set of
`org-speeds-commands' to the user for customization is an improvement
over the previous state of affairs. However, I believe there were some
unintended consequences of this change that can make it difficult to
customize `org-speed-commands' for users that are not elisp gurus.

The main problem is that `org-speed-commands' serves two purposes

1.) It contains all the mappings between speed keys and commands
2.) It contains headlines for command categories.

Because of this second purpose, both the contents and order of entries
in `org-speed-commands' are important. For example, suppose I want to
replace the usual "n" command with my own. According to the usual
conventions for alists
new associations such as this are added to the front of the list. But
if I do so, by doing something like:

  (setq org-speed-commands (cons '("n" . #'my-org-next-heading)

Then the speed key "n" will show up twice when
`org-speed-command-help' is invoked. I could first delete the old
association by replacing `org-speed-commands' in the above with
`(assoc-delete-all "n" org-speed-commands)', but then my modified
command will no longer appear in the "Outline Navigation" section of
the speed command help. Alternatively, I could replace the association
for "n" using `alist-get':

  (setf (alist-get "n" org-speed-commands nil nil #'equal)

However, this solution won't work for new speed commands (e.g., if I
want to bind `my-org-next-heading' to "N" instead), because in that
case `alist-get' will return `nil'.

Below is the relevant portion of my config file where I customize
  (defun alist-set (key value alist-symbol &optional testfn)
    "Set KEY to VALUE in alist referenced by ALIST-SYMBOL.

  If KEY is not present in the alist, then add (KEY. VALUE) to the
  front of the alist. Compare keys with TESTFN. Defaults to equal."
    (if-let ((keyval (assoc key (eval alist-symbol) testfn)))
        (setf (cdr keyval) value)
      (set alist-symbol (cons (cons key value) (eval alist-symbol)))))

  (defvar sbr-org-speed-commands-user '(("User Custom Speed Commands")
                                        ("N" . ded-org-show-next-heading-tidily)
                                        ("P" .
                                        ("h" . sbr-org-speed-insert-subheading)
                                        ("u" . org-up-heading-or-item)
                                        ("b" . org-backward-heading-or-item)
                                        ("f" . org-forward-heading-or-item)
                                        ("p" . org-prev-heading-or-item)
                                        ("n" . org-next-heading-or-item))
    "My custom Org speed commands")

  (dolist (keyval (reverse sbr-org-speed-commands-user))
    (alist-set (car keyval) (cdr keyval) 'org-speed-commands))

As you can see, I defined my own function `alist-set', which modifies
an association in an alist if the key is already present, or adds the
new association to the front of the list otherwise. In my opinion,
functionality like `alist-set' should be built into Emacs itself. My
code then constructs my own list of custom speed commands with its own
section header and uses `alist-set' to add/modify speed commands.
While this code works, it's a bit unsatisfying because

1.) It relies on my custom `alist-set' function
2.) It relies on knowledge of the structure of `org-speed-commands'

More specifically, it requires that my new speed commands need to be
inserted in reverse order into `org-speed-commands' in order to be
displayed properly in `org-speed-commands-help'.

I don't know what is the best solution to enable Org users to add
and/or modify speed commands while also keeping the display of
`org-speed-commands-help' organized. Here is what I propose:

1.) Keep the whole set of `org-speed-commands' exposed to user
customization for power users
2.) Bring back `org-speed-commands-user', but instead of just
appending it to `org-speed-commands' as was done prior to Org 9.5, use
something like my `alist-set' above to add/modify speed command
associations as needed while preserving the display order in

With my proposal, Org users wouldn't have to concern themselves with
the section headers in `org-speed-commands', but they would still be
able to add/modify/remove commands as they wish.

Let me know if anyone has a simpler alternative to achieve these
goals. If there is sufficient interest in my proposal, I would be
happy to provide a patch.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-05-18 13:13 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-24  9:36 Unintended consequences of removing org-speed-commands-user Shankar Rao
2021-11-28 12:15 ` dal-blazej
2021-11-30 12:13   ` Shankar Rao
2021-11-30 14:19 ` [PATCH] New function org-speed-command-add for adding/modifying speed commands Shankar Rao
2022-05-03 10:24   ` Ihor Radchenko
2022-05-17 13:01     ` Shankar Rao
2022-05-18 13:12       ` Ihor Radchenko

Code repositories for project(s) associated with this inbox:


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).