Hi Ihor,
Ihor Radchenko <yanta...@posteo.net> writes: > TL;DR: We are in the process of designing a more unified selection > interface for Org mode and want to see if there is some way to unify > context-menu-mode, transient, which-key and embark together. The idea > is to (1) avoid too many customizations; (2) allow users to decide how > to choose between multiple options - by mouse, keyboard, and using > customizable UIs. I think that the built-in Emacs thingatpt.el should not be overlooked here. Instead of implementing an entire system specific to Org, imagine a generic action-at-point interface that works on "things" from thingatpt.el. For the various targets, Org could add new "providers" to `thing-at-point-provider-alist', `forward-thing-provider-alist', and `bounds-of-thing-at-point-provider-alist'. [ Org actually does already register its own 'url' provider for links. ] Then, Org could implement a number of action selection interfaces that act on the various classes of "thing". An exemplary package would be Philip Kaludercic's great =do-at-point= package, which provides a simple action selection menu for the thing-at-point using `read-multiple-choice', which I find elegant and intuitive.[1] I have gone as far as implementing a 'heading' provider for Org and `outline-mode' (for use with =do-at-point.el=). I don't see any reason why Org couldn't define a 'citation' provider, a 'source-block' provider, etc. The only downside that I have found with adding lots of thingatpt.el providers is that it can be difficult to write providers efficient enough for `forward-thing' in particular (`forward-thing-provider-alist'). I may also be misunderstanding the proposed interface. For example, instead of a generic interface for acting on a single thing at point, maybe you are describing more of an interface for associating commands with multiple potential targets that must be located (e.g., in a subtree), which are then each associated with actions. Even if that's the case, there is a good case for implementing thingatpt.el providers for the targets, so that users could bring our own action-at-point packages/interfaces. [ I would be willing to help write some of those providers. ] And if thingatpt.el isn't generalized or fast enough, then there is a case for creating a new, more flexible /de facto/ library like this for Emacs. [1] https://codeberg.org/pkal/do-at-point Thanks, Kierin
