oantolin
General org target finder
Separate issue for continuation on discussions from here and here.
tl;dr; I have written a target finder for org that uses org's own parser which atm can be found here. It is easy to extend for users.
I have signed the copyright papers for Emacs if this ends up becoming a PR.
Per my comment over there, just wanted to make sure you're aware of the native org-cite functionality that's about to be merged.
That includes new citation and citation-reference org objects.
At bibtex-actions, we're actually including a target finder for it, with the intention to turn it into a "follow" processor.
https://github.com/bdarcus/bibtex-actions/pull/143 https://github.com/bdarcus/bibtex-actions/issues/141
To repeat my opinion regarding this generic org target finder and org actions in general:
- I prefer to have a flat list of finders, not something nested. While one saves the parsing effort with the nesting, the advantages are marginal. Embark target finders are not performance critical. By providing appropriate helper functions it is easy to create a target finder corresponding to an Org object, such that everything stays easily extensible and one avoid code duplication.
- The first step should be to identify the actions we want to have here. There are two other projects we can use for reference:
- How can one add such target finders, such that they are not always loaded? Most finders should only be enabled if orgmode is loaded and active. There is however one scenario, where this approach is lacking: It would be nice to have global org link actions, in the style of
org-open-at-point-global. There are org link regular expressions which could be reused. This allows to use org links as Hyperbole-style buttons everywhere. See my Hyperbole/Org comment on reddit. - For org actions at point it may be useful to have repeatable actions (see #244 and #245). cmap has repeatable actions too mainly for org actions at point.
- Of course there is the question if we need this at all. Org already provides a rich set of keybindings for all the various operations one may want to perform on the object at point. What do we win by embarking these commands?
Org already provides a rich set of keybindings for all the various operations one may want to perform on the object at point. What do we win by embarking these commands?
Good question.
I guess it's only valuable if you want to add access to additional contextual actions beyond those provided in org.
It makes sense for the new org-cite, for example.
Daniel Mendler @.***> writes:
To repeat my opinion regarding this generic org target finder and org actions in general:
I guess I'll repeat my response too (I think my opinion has changed but whatever). :P
- I prefer to have a flat list of finders, not something nested. While one saves the parsing effort with the nesting, the advantages are marginal. Embark target finders are not really performance critical.
I can agree with this. Instead I propose to just have the org link target finder. The code that would be added to embark would look something like this:
(defvar my/embark-org-link-type-alist nil
"An (LINK-TYPE . ACTION-TYPE) alist to determine which link types has its own embark actions.
See `my/embark-target-org-link'.
LINK-TYPE is a string of the part before the colon in an org link.
ACTION-TYPE is a symbol and should be a key in embark-keymap-alist.")
(defun my/embark-org-link-finder ()
(when-let ((context (org-element-context)))
(when (eq (car context)
'link)
(let ((type (plist-get (cl-second context)
:type))
(path (plist-get (cl-second context)
:path)))
(if-let ((matched-type (alist-get type my/embark-org-link-type-alist
nil
nil
#'string=)))
(cons matched-type path)
(cons 'url path))))))
It is one target finder for org links, but the user can customize which keybindings corresponds to which link types by adding a cons cell to the my/embark-org-link-type-alist variable (e.g. (cite . org-ref-cite-link) for org-ref style cite links).
Org already provides a rich set of keybindings for all the various operations one may want to perform on the object at point. What do we win by embarking these commands?
Good question.
I guess it's only valuable if you want to add access to additional contextual actions beyond those provided in org.
It can also help with discoverability, to see what operations are available at point without needing to know the existing functionality
See also, the new org-ql-find command in org-ql. Documentation and screenshot: https://github.com/alphapapa/org-ql#org-ql-find
As things turned out, I wound up implementing a slightly different org target finder in the embark-org library. I still don't have key bindings for all the actions that @sheijk's org-menu package provides in its transient menus, but I already find embark-org useful. I definitely welcome any suggestions for embark-org on either new org elements to target (which is as easy as uncommenting them in the definition of embark-org--types) or of new actions to add to the keymaps.
