From: Shankar Rao <shankar.rao@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Unintended consequences of removing org-speed-commands-user
Date: Wed, 24 Nov 2021 10:36:37 +0100 [thread overview]
Message-ID: <CAGEgU=gm=hRVw6g5wzjEwRx_1=K8haeWZn1KRQtRYWVGi2z-GQ@mail.gmail.com> (raw)
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
simultaneously:
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
(https://www.gnu.org/software/emacs/manual/html_node/elisp/Association-Lists.html),
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)
org-speed-commands))
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)
#'my-org-next-heading)
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
`org-speed-commands':
-----
(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" .
ded-org-show-previous-heading-tidily)
("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
`org-speed-commands-help'.
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.
Thanks,
Shankar
next reply other threads:[~2021-11-24 9:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 9:36 Shankar Rao [this message]
2021-11-28 12:15 ` Unintended consequences of removing org-speed-commands-user 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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGEgU=gm=hRVw6g5wzjEwRx_1=K8haeWZn1KRQtRYWVGi2z-GQ@mail.gmail.com' \
--to=shankar.rao@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.