Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)

[Panayotis Manganaris <panos.manganaris@gmail.com>]

Hello. I'm very much an elisp amateur, but one of my main motives for
learning has been to make use of emacs' many beautiful UI systems.

Therefore, I'll provide my comments from a designer perspective and
avoid implementation detail.

Ihor Radchenko <yantar92@posteo.net> writes:

> TL;DR: We are in the process of designing a more unified selection
> interface for Org mode

Thanks to Tor-björn, Jonas, Ihor, and everyone else for this work. I've
learned much by following this thread.

> a number of people raised concerns that transient may sometimes be an
> overkill

I agree with others that transient is overkill for most of the menus in
org-mode. A counter argument, going by the patches exchanged here, might
be that transient menus are a clean and scalable approach.

I've not tried the in-dev transient follow processor, but I imagine it
is similar to the old org-ref (John Kitchin) hydra menu. I used org-ref
for years, and enjoyed how its menu united many features, including
- a system analogous to org-cite follow processors for navigating to sources/notes
- a system akin to reftex-mode for org
- a system for downloading new references and making new bibliography entries

With this level of complexity, a transient menu seems like the modern
weapon of choice for a similar feature set. Only, wait, I stopped using
org-ref.

Long story short, I concluded that treating org-mode like a nexus for
these intertwined features was, at least, encouraging my bad habit of
treating org-mode as an "everything app."

I have since delegated the task of populating my personal library to a
dedicated reference manager. I started using latex-mode and reftex to
write papers, thus gaining more typesetting control and making version
management much easier. I still use org to take notes, but now enjoy a
much more stable and focused configuration.

I tell this story as an (anecdotal) case study for how a powerful menu
can be less productive in the long run. Org-ref's hydra menu is not to
blame for my bad decisions but, at least in-part, I used it (and even
extended it) because a greater man put it there.

Scalable design is an invitation to scale. Perhaps the wise know better.
Anyway, the simple tasks of navigating from a citation link to a copy of
the original document, its URL, or an associated note is achievable with
a completing-read (helm, counsel, vertico, etc.) interface.

Transient is overkill.

> This UI flow can be implemented using context menus [...] embark

I like org's context menus, but I like embark better. I do think it
would be very generous of org to delegate its own contextual actions to
embark if so configured.

I'll elaborate:

As is, I like to run org-babel code block functions through embark, I
only wish there were more of them to run. I find this to be far superior
in every way to binding equivalent key chords for the mode.

Also, for me, embark-bindings and embark-prefix-help-command have
completely replaced which-key for discovering key bindings on-the-fly.

> I am wondering if we can work out some universal API to plug the
> described action->menu->selection model into the UI that user prefers.

I support this idea in principle.

> 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...)
>    PROPS is a plist defining extra properties like key-binding, display
>    string, maybe something else to be used in the future.

I would focus on associating just enough metadata with functions to
enable using them with embark. I really have no idea what the best way
to do this is. This seems to be the biggest missing piece.

Maybe in the short term we just crowd-source some embark configuration
on WORG.

Menus should of course be useful without embark. If the goal here is to
deprecate many of org's ad-hoc interfaces, I think the natural default
replacement for most is completing-read. I may be completely wrong.

> 2. Menu interface to use (transient, context-menu, embark, which-key)

It seems like Tor-björn and Ihor have already laid the groundwork for
using transient in this way. So, I'll just say bravo. Regardless of my
opinion on transient overuse, it looks like great work.

On the other hand, e.g. if the org export dispatch menu isn't transient,
it should be. Seems obvious to me.

> 3. Layout settings for the specific interfaces. For example, transient
>    layout definition.

It is important to avoid making more org-mode-specific UI abstractions.
Whatever the solution, it is important that the UI implementations
tapped to take over help share the maintenance burden.

In this way, I reckon most interface customization can be done in hooks.

> WDYT?

Ideally org-mode uses established APIs rather than making another.

Thanks for reading, and thanks for the chance to contribute.