Re: Proposal: 'executable' org-capture-templaes

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> I'm not sure I really understand the exact goal you have here. To me, it
> feels like yet another input selection/menu/completion scheme and I'm
> not clear on how it will be an improvement or why do something
> 'different' in org compared to other modes etc. However, I also don't
> have any problems using the existing capture interface, so perhaps I
> just don't have the number or complexity of capture choices to expose
> issues/limitations wiht the existing approach. 
>
> The main 'concern' (well, not really a concern, but ....) I have is that
> Emacs already has far too many solutions along this line, which makes it
> harder to get a consistent UI. I also feel this is one of those areas
> which appears to be really easy to 'fix' or improve, but also has a lot
> of hidden complexity which only becomes evident once lots of different
> users and workflows try to use it. 

Let me clarify my vision of this thread.

1. Arthur is interested to implement something similar to org-capture
   menu. We can help him with this regardless of our stance on whether
   to include the result into Org.

2. Org mode has multiple implementations of menu. Menus for org-capture,
   org-export, org-todo, org-set-tags-command, and org-agenda are all
   implemented independently creating redundancy in our codebase.

3. Because of the redundancy, there has been a proposal in the past to
   switch from our existing menus to transient. However, it will be a
   breaking change. We would prefer to support old menus as well (at
   least for a handful of years)

4. If Arthur's implementation turns out sufficient to replicate the
   "look and feel" or our existing menus, we can use it instead. This
   will at least reduce the amount of menu code in Org. We can also take
   this opportunity to make the menu backend selectable: the old menus,
   Arthur's menu backend, transient. Then, we can eventually drop the
   old menus backend and leave Arthur's + transient. They will be much
   easier to maintain, especially if Arthur's implementation can be
   distributed as separate package (even if not, one menu implementation
   is easier than multiple that we have now).

Best,
Ihor