From: Arthur Miller <firstname.lastname@example.org>
To: Ihor Radchenko <email@example.com>
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Mon, 30 May 2022 04:04:39 +0200 [thread overview]
Message-ID: <AM9PR09MB4977054FA64BDB6E7B562E9896DD9@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <87pmjyco0x.fsf@localhost> (Ihor Radchenko's message of "Sat, 28 May 2022 11:51:58 +0800")
Ihor Radchenko <firstname.lastname@example.org> writes:
> Arthur Miller <email@example.com> writes:
>> Simplicity comes from the org-templates. Me, and I guess other people are
>> familiar with org-catpure templates already, and I mean, can it be simpler to
>> create a menu of choices then a simple list:
>> '(("key1" "label1" exec (lambda () ...))
>> ("key2" "label2" exec (labmda () ...))
>> People are already writing those as part of org-capture, so there is a
>> familiarity factor. Transient has to be learned, and the complexity is much
>>> If anything, capture
>>> menu might be factored out to a generic menu framework.
>> Please no. Not every single piece of Emacs has to be a generalized
>> framework. Generalized frameworks add an extra layer of complexity, and it this
>> case, as you point out, we have other frameworks, so yet another framework is
>> *definitely* not what I ask for.
> By "generic" I did not mean general-purpose all-functional framework.
> We just need something to remove code duplication in
> org-export-dispatch, org-agenda, org-capture, org-set-tags-command, etc
> They all share pretty similar code to generate dialogues.
> As for familiarity, I understand and it is exactly the reason why I
> suggested to factor out the menu code from capture templates.
I am not really familiar with those other dialogues but org-capture, so I only
had that one in the mind. Yes, I agree if the similar code is used/shared in
several places than it does make sense to refactor it out.
> I am strongly not in favor of adding exec to org-capture itself. It's
> a bit like if you were to add :activate-func for a link that actually
> downloads some file from internet, then generates and exports agenda,
> and meanwhile also restarts your remote server. This will also kind of
> save the code, but completely out of purpose of :activate-func. Of
> course, I am exaggerating here, but just want to make my point clear.
I understand, it is ok :).
>>> We actually had multiple threads discussing possibility to port all the
>>> Org dialogues to transient.
>> I have unfortunately missed those discussions. But as said, I am not in to argue
>> for or against transient at all. I would just like to re-use the org-capture
>> code, since it is already in-place.
> The last one was
> And we had multiple complaints that Org menus are not searchable and do
> not allow recursive edit.
I am not sure what complain about searchability is/was, so I should not say much
there, but those are just a list of lists, saved in a well-known place,
org-caputre-templates var, so one can always traverse that list, or search the
menu buffer itself. Anyway thanks for the link, I have read through
that discussion. Seems to me like most of you are in favour of refactoring org
to use transient everywhere?
>>> It seems to be quite out of scope of org-capture.
>> Maybe, but than what is in scope of org-mode or org-capture or Emacs? We are
>> constantly bending code to do what it is not really meant to do. Since to be a
>> DNA of Emacs :).
> Sure. But another feature of Emacs is being consistent. Emacs does
> provide flexible interfaces, but they stick to they purpose. Abusing
> them is up to the user (with no guarantees to work in future versions),
> but not up to Emacs itself.
> If we were to include your suggestion, we would also need to maintain
> the new generalized functionality in future. Even if we need to change
> some internals of org-capture. Over-generalization will put an extra
> burden on future maintenance.
Np, I understand. Thanks for the answer anyway.
next prev parent reply other threads:[~2022-05-30 2:11 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 [this message]
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
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).