Kierin Bell <ferns...@fernseed.me> writes: > 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. ]
This is actually not what I had in mind in this thread. I was only hoping to get input about customizing menu interface in a way that menu UI can be chosen by user. As for `thing-at-point', it is not enough for Org's needs. Let me show you an example of one of the Org "action" commands. org-ctrl-c-ctrl-c does the following: 1. If performs specific actions depending on Org syntax element at point 2. It performs alternative action in Org edit buffers where org-finish-function is defined. 3. It performs different things depending on context around thing at point. For example, first paragraph inside a list will trigger a different action compared to just a paragraph. While (1) can be easily ported to thing-at-point, (2) is much harder, and (3) will involve creating artificial "things" just for the purposes of specific Org command. > 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'd like Org _not to implement interfaces_. Instead, I want to reuse the existing interfaces - transient, menus, which-key, etc. My main question is whether we can do such thing cleanly. > 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. Yup, something more like this. > 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. Better interoperability with thingatpt.el will be certainly welcome. I even coined this idea in the context of tree-sitter in the past. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
