From: Max Nikulin <email@example.com>
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Tue, 21 Jun 2022 22:48:18 +0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 21/06/2022 11:07, Ihor Radchenko wrote:
> Max Nikulin writes:
> The other question is altering the org-capture code.
> I think that it is too early to discuss org-capture part just yet.
> Lets first finalize the generic library itself and discuss the
> appropriate adjustments to
> org-capture/org-agenda/org-export/org-todo/etc code later.
From my point of view changing menu without adjusting calling logic is
a kind of trade-off with uncertain net result. New UI may significantly
affect different user expectations. It seems this is the point of our
disagreement. You tend to consider menu in isolation trying to postpone
the question concerning interaction of code running before menu creation
and handlers of menu items (they are not belong to the same call stack
What I am really afraid is words like:
> Sure. That somewhere can be buffer-local variable inside the capture
> menu buffer. Or global variable. Or closure. How is it relevant to the
> capture menu?
I am trying to avoid implementation of menu that would make passing
state to handlers unreliable or prohibitively complicated.
Global variables are certainly not an option because such approach does
not allow several instances of menu created in parallel.
To use buffer-local variables some support from the side of menu library
is required. Buffer does not exist when menu function is called. So
either some callback should be passed to menu to be invoked when a new
buffer is created for menu or that buffer should be returned from the
menu creating function. Unsure if (current-buffer) would be a reliable
Closures should work, but would be it convenient enough?
Maybe some intermediate layer should be introduced to make alternative
implementation of menu (transient, completing read, etc.) easier.
I believe, discussing design of menu without evaluation if it is
suitable to features that should use it (capture, agenda, etc.), there
is a risk to create unreasonable restrictions on further steps.
That is why I consider the following aspects of menu design as essential
- A clearly determined way to pass some state from a function that
requests creation of menu to handlers of menu items.
- When a non-blocking technique to wait user decision is used, multiple
instances of the same menu should be allowed.
- Defined extension points for alternative implementations to avoid code
duplication and divergence of behavior.
My fear is that if such points are ignored in the beginning, it may
become impossible later.
next prev parent reply other threads:[~2022-06-21 15:50 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 15:27 Proposal: 'executable' org-capture-templaes Arthur Miller
2022-05-27 5:27 ` Ihor Radchenko
2022-05-27 12:17 ` Arthur Miller
2022-05-27 14:35 ` Max Nikulin
2022-05-28 3:51 ` Ihor Radchenko
2022-05-30 2:04 ` Arthur Miller
2022-05-30 5:05 ` Ihor Radchenko
2022-05-30 12:40 ` Arthur Miller
2022-05-31 4:58 ` Ihor Radchenko
2022-05-31 14:46 ` Arthur Miller
2022-06-04 15:35 ` Arthur Miller
2022-06-05 0:04 ` Ihor Radchenko
2022-06-05 15:16 ` Arthur Miller
2022-06-05 23:05 ` Tim Cross
2022-06-08 12:43 ` Ihor Radchenko
2022-06-08 21:13 ` Tim Cross
2022-06-09 4:00 ` Ihor Radchenko
2022-06-17 4:40 ` Arthur Miller
2022-06-18 4:03 ` Ihor Radchenko
2022-06-18 4:26 ` Tim Cross
2022-06-18 12:25 ` Max Nikulin
2022-06-08 12:24 ` Ihor Radchenko
2022-06-05 7:36 ` Max Nikulin
2022-06-05 15:07 ` Arthur Miller
2022-06-06 17:06 ` Max Nikulin
2022-06-07 3:09 ` Samuel Wales
2022-06-07 3:16 ` Samuel Wales
2022-06-08 12:48 ` Ihor Radchenko
2022-06-10 16:53 ` Max Nikulin
2022-06-11 5:26 ` Ihor Radchenko
2022-06-18 8:18 ` Max Nikulin
2022-06-18 8:25 ` Ihor Radchenko
2022-06-19 11:20 ` Max Nikulin
2022-06-20 12:10 ` Ihor Radchenko
2022-06-20 17:24 ` Max Nikulin
2022-06-21 4:07 ` Ihor Radchenko
2022-06-21 7:38 ` Arthur Miller
2022-06-21 15:48 ` Max Nikulin [this message]
2022-06-22 12:13 ` Arthur Miller
2022-06-22 16:29 ` Max Nikulin
2022-06-26 4:50 ` Arthur Miller
2022-06-29 17:02 ` Max Nikulin
2022-06-30 23:30 ` Arthur Miller
2022-07-01 15:53 ` Proposal: 'executable' org-capture-templates Max Nikulin
2022-06-25 7:32 ` Proposal: 'executable' org-capture-templaes Ihor Radchenko
2022-06-26 4:25 ` Arthur Miller
2022-06-26 4:37 ` Ihor Radchenko
2022-06-26 4:52 ` Arthur Miller
2022-06-21 7:37 ` Arthur Miller
2022-07-02 11:31 ` Max Nikulin
2022-07-03 15:12 ` Arthur Miller
2022-07-07 16:14 ` Proposal: 'executable' org-capture-templates Max Nikulin
2022-06-18 15:05 ` Proposal: 'executable' org-capture-templaes Arthur Miller
2022-06-19 10:53 ` Max Nikulin
2022-06-19 15:34 ` Arthur Miller
2022-07-03 3:32 ` Max Nikulin
2022-06-08 12:35 ` Ihor Radchenko
2022-05-31 16:37 ` Max Nikulin
2022-06-01 1:45 ` arthur miller
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).