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 <yanta...@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.
