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

[Tim Cross]

Ihor Radchenko <yantar92@gmail.com> writes:

> 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).
>
Hi Ihor,

I think I totally get where your coming from and I agree with all
points. However, I don't quite get exactly what Arthur is proposing at a
concrete level. 

Overall, I guess my main concern is that this is one of those areas
where it looks deceptively easy to improve and it is only once you get
down into the weeds and start to see all the competing perspectives, you
realise how much more complicated it actually is. 

To some extent, it reminds me of what I always found so frustrating wiht
CL. In general, it was so easy to create a new library representing some
functionality that everyone did it. Instead of having one good solution,
we end up with 20 ok ones. Worse still, we end up with 10 different
implementations within the same code base.