From: Nicolas Goaziou <firstname.lastname@example.org>
To: No Wayman <email@example.com>
Subject: Re: [RFC] DOCT: Declarative Org Capture Templates
Date: Fri, 24 Apr 2020 12:01:20 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (No Wayman's message of "Thu, 23 Apr 2020 13:30:25 -0400")
No Wayman <firstname.lastname@example.org> writes:
> * [RFC] DOCT: Declarative Org Capture Templates
Thank you for your work.
I have some comments.
Disclaimer: I am only using very basic capture templates. So, I cannot
comment realistically on the new syntax you suggest. In particular, the
example you give is way too complex for me to understand the benefits of
your syntax. I suggest to start out with showing simple use-cases.
Anyway, I hope more advanced capture template users can chime in and
comment your design.
My beginner questions are the following :
- Is it compatible with the current syntax? If it isn't, is there a way
to ease transition to the new syntax?
- Is it simple to use on simple use-cases?
- Is it more capable than the current syntax, i.e., does it handle
situations that are not possible, even in a convoluted way, currently?
> - DOCT validates templates before runtime execution.
> For exmaple, you have a template with an entry type of `'entry'
> and you forget the leading star in the template string.
> Days later you go to use that template. It's borked.
This is different from introducing a new syntax for capture templates.
Actually, `org-insert-place-item' and `org-capture-place-table-line'
both try to fix misshaped templates already. OTOH
`org-capture-place-entry' merely calls `org-capture-verify-tree' on the
template, i.e., it barfs if the template is ill-defined. It is
a discrepancy we could fix independently on your new syntax.
I invite you to propose a patch for `org-capture-place-entry' so it does
a better job at fixing the initial template, if needed. I'll gladly
next prev parent reply other threads:[~2020-04-24 10:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 17:30 No Wayman
2020-04-24 10:01 ` Nicolas Goaziou [this message]
2020-04-24 18:01 ` No Wayman
2022-03-20 10:19 ` [RFC] DOCT: Declarative Org Capture Templates (easier template syntax) Ihor Radchenko
2022-03-20 13:17 ` Nicolas Goaziou
2022-03-21 9:14 ` Ihor Radchenko
2022-03-23 16:31 ` Nicolas Goaziou
2022-03-23 21:28 ` Tim Cross
2022-03-24 0:39 ` No Wayman
2022-03-26 8:30 ` Ihor Radchenko
2022-03-27 14:46 ` Ihor Radchenko
2022-03-29 14:19 ` Matt Price
2022-03-20 15:56 ` Mark Barton
2022-03-21 8:51 ` Ihor Radchenko
2022-03-23 14:32 ` João Pedro de Amorim Paula
2022-03-24 18:43 ` physiculus
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).