emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Arthur Miller
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Fri, 17 Jun 2022 06:40:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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).

Hello, and sorry for long time no hear ... thought I would had something last
weekend, but it took a bit longer time.

Anyway, I have been playing and testing a bit, and didn't want to prolong
discussion untill I have something to show. So here is a small prototype. It is
just a rough sketch of the idea.

The idea is simple: just ordinary keymap, with automated mode and keymap
creation from templates.

It uses simple template format to specify a key and a label to display in a
buffer for the user. It can either return the template back to some callback, or
it can use the 3rd argument as "executable" and wrap it in an interactive lambda
to tuck into the keymap. I think that it is the minimum required. Rest is a
boilerplate. It also puts declaration of gui and logic in same place (the
template).

For example org-capture defines its own template language, so it is just to give
the chosen template to org-capture. This is what org-mks does, pretty much. I
have just refactored the org-capture in an example to show that it is possible
to implement the equivalent with almost no changes, more than it does not use
org-mks under the hood. There is no code saving there.

However, when it comes to org-agenda, as I see from the current implementation
it does not use org-mks at all, but does something very similar on it's own,
with ui and logic hardcoded in `org-agenda-get-restriction-and-command'. In
this example the mode map approach seems slightly more convenient. I don't know,
in org-agenda-test, I haven't implemented all of org-agenda, restrictions,
prefixes and some other stuff, mostly because I don't really understand the
implementation. I didn't want to sitt too long and figure out how stuff works,
if the fundamental approach is not acceptable, but I have implemented quite few
of the menu choices, at least to show the pattern.

As said, it is just a rough sketch to illustrate the idea. I am not sure myself
if it is good idea or not. I have implemented it so it works with org-capture
templates, and I hope it wasn't too much of extra "customizations" tossed
in. "Horizontal" menu was needed to simulate org-agenda looks, otherwise the
code would be much smaller. Also to note is that the "logic" does not use
anything in buffer on display, so it would be possible for someone interested to
"rice" it up after the drawing is done, so the customization options could be
further reduced.

To answer some questions I have seen in mails, sorry for late answeres:

@Ihor
I really don't have problem with "read key". Originally I just wanted to extend
org-capture templates to do a bit extra :).

Actually org-mks and similar approach is really efficient in terms of
resource (no minor/major modes etc). It is only the thing if same framework is
to be used by non-modal applications too, than there have to be other way to
read user input, and since the other way are keymaps, read-key becomes 
redundant.

Sometimes, something like 'read-key' is what is needed, and sometimes that is
just enough. When I first thought of using org-capture templates for
"executable" definitions, I really didn't know how org-capture worked under the
hood. Max is correct about wrapper, that is how org-capture works. But since it
is so easy, we can also automate it and skip writing wrappers and lambdas every
time we use it. That is the idea behind the "default handler" in the
example.

Big difference with org-mks vs ordinary mode-map based menu, is that org-mks
locks entire session. Modal behaviour is used to ensure that just one task at
the time is manipulating org files. I think it can be achieved by other means
too. I have not done it correctly in the example :), but I think it is possible.

I am including also an older test which I have later refactored, that has
"read-key" interface (in org-select-modal); i.e it behaves similar to org-mks,
just to show that such modal interface can be tucked on. It just reads a key
from the user and then invokes the command from the mode map. It is very crappy,
but it shows that both

@Tim
Thank you for mentioning emacspeak. I have never used it so I don't know how it
works, but I have taken a look at some code in Emacspeak after your mail.

Also if I understand what you and Ihor say, it needs to get labels echoed to
minibuffer in order to work with Emacspeak? I have done it so, I am not sure if
works always though :).

@Max
I agree with you that completing read is a good alternative, but it is a bit
like discussion about GUI vs. terminal. I am personally heavy user of Helm, but
not everyone is I believe.

About the name: org-select; i really have no idea what to call it, so better
name would be nice. Sorry for the bugs, I am aware of many, but it still
displays the idea I think.

Attachment: org-select.el
Description: Text document

Attachment: org-select-modal.el
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]