Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?

[Ihor Radchenko]

Kierin Bell <fernseed@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>