From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Bastien <bzg@gnu.org>
Cc: Florian Lindner <mailinglists@xgm.de>, emacs-orgmode@gnu.org
Subject: Re: Capture template stopped working: nil
Date: Sat, 01 Jul 2017 11:03:37 +0200 [thread overview]
Message-ID: <87mv8o4jh2.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87a84pslz2.fsf@gnu.org> (Bastien's message of "Fri, 30 Jun 2017 14:23:29 +0200")
Hello,
Bastien <bzg@gnu.org> writes:
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Bastien Guerry <bzg@gnu.org> writes:
>>
>>> May I ask you why `eval' in the code base is problematic?
>>
>> Because 1. it is hideous, 2. it doesn't cope well with lexical
>> binding.
>
> Can you provide with an example on how `eval' can lead to trouble
> due to lexical binding for the org-capture configuration?
>
> I'm trying to understand.
I never said `eval' could lead to trouble due to lexical binding in Org
capture configuration. I said `eval' is a problem in the code base,
notwithstanding its location.
Moreover, allowing Sexp in a capture template is really abusing
homoiconicity of the language. As soon as the S-exp becomes mildly
complex, the resulting template is unreadable. OTOH, using a function
right from the start clarifies the structure of the template. The
occasional `(concat a b)' is not a sufficient reason, IMO, to allow
`eval' there. We should encourage saner practices.
>> Using `eval' should be made with extreme parcimony and for very
>> consensual reasons.
>
> Yes, but unless we fix a realistic bug, not bothering the user with
> backward-incompatible changes should take over IMHO.
Let's consider `eval' in the code base a coding design bug, then.
A clearer code base (e.g., more comments, less obscure variable names,
more expressive syntax) is something we should strive for.
Anyway, this is a rather small incompatible change we're talking about
here. In particular, it doesn't change document syntax. It's
a straightforward modification of some configuration. Not as bad as it
sounds, really. Note we already did the same for `org-file-apps' in Org
9.0 (although the reason was different).
Regards,
--
Nicolas Goaziou
prev parent reply other threads:[~2017-07-01 9:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-25 19:04 Capture template stopped working: nil Florian Lindner
2017-06-25 19:09 ` Nicolas Goaziou
2017-06-25 19:23 ` Florian Lindner
2017-06-30 10:20 ` Florian Lindner
2017-06-30 11:13 ` Alan Schmitt
2017-06-30 12:39 ` Nicolas Goaziou
2017-06-25 19:44 ` Bastien
2017-06-25 20:24 ` Nicolas Goaziou
2017-06-25 21:25 ` Bastien Guerry
2017-06-25 21:38 ` Nicolas Goaziou
2017-06-30 12:23 ` Bastien
2017-07-01 9:03 ` Nicolas Goaziou [this message]
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mv8o4jh2.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=mailinglists@xgm.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).