>>>> No to be a devils advoce, but I am not sure you do. If we look at: >>>[...] >>>> ‘%(EXP)’ >>>> Evaluate Elisp expression EXP and replace it with the result. The >>> >>> I agree with Ihor that using "(EXP)" here should help to avoid ambiguity. >> >> I am sorry, I am not trying to be impolite, but they are both *equally* >> ambigous for the same reason I took up in previous two mails. > >> .. >> It is not about being "ugly" or "pretty". It is about being consistent >> with Lisp. Double parenthesis arise in other places too, that is not a >> big deal in Lisp. > > I have updated the documentation. Hopefully the ambiguity will not be > there anymore. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0f534d5d6
To be honest to you, and I hope I am not misstaken to be some a petitess
person, that is not my intention, but I think the problem here is the
usage of the word "expression", since symbol expression has a determined
and clear meaning in Lisp. I think the problem here is that placeholders
are using parenthesis, and a symbolic expression is also using
parenthesis for lists. When I see this %(), I see a placeholder
notation. And when I see EXP or expression, I see something can be (+ 2
3). Thus if you put together those, I see %((+ 2 3)) as the natural
result. However, the implementation turns the placeholder to be the part
of the expression. Thus the placeholder is just "%", somehow. But we
still can't type somethin like %default-directory, so it all comes out
weird to me. Just my 2c as they say.
> I think %(EXP) notation comes back to diary sexp format %%(EXP) (see
> 33.10.5 Special Diary Entries in Emacs manual).
>
> We have the same format in capture templates and also in agenda prefix
> format.
I have never used diray sexp format, didn't even know it existed, but I
wouldn't be surprised it does the same.
> Also, I find %((EXP)) less intuitive than %(EXP) and I never had any
> issues with the existing format, so your perspective, while valid, is
> not unique.
I find it on the contrary, since I am thinking from the Lisp side of
things, as explained above.
Anyway, the content of my suggestion was an improvement to make
org-capture templates a little bit more user-friendly to use in bigger
templates. In small capture templates it is not a problem to not be able
to use variables. When you have only one place where you want to call a
variable, typing (princ myvar) is not a problem. It becomes problematic
if you would like to use it, like me, to expand entire files. Repeating
ourselves all over the place, possibly many times as in the attached
example of the readme, is clunky and unnecessary. I have suggested
another patch, in the other mail, completely unobtrusive and backwards
compatible.
I can suggest even more simplified one. The attached here is one that
only extends fill-template function with optional function object to be
used as evaluator. That is all I would need. Unfortunately, due to the
desing of org-capture-fill-template, I can't just advise it. I have to
completely replace or use a completely new function, i.e. new framework.
I think it would be a bit shame to not make it more general, since it is
so little extra work needed. See the previous patch in the other mail.
There are also two other problems. org-capture-fill-template calls
unconditionally untabify. There is no note why the original author calls
this, but that seems unfortunate, since it does respect the users
choice. A user might wish to have a tab in their expanded template. For
my part for example, consider a templatized Makefile, something like
this:
______________________________________________________________________
LISP ?= sbcl
all: test
run:
rlwrap $(LISP) --load run.lisp
build:
$(LISP) --non-interactive \
--load %(project-name).asd \
--eval '(ql:quickload :%(project-name))' \
--eval '(asdf:make :%(project-name))'
test:
$(LISP) --non-interactive \
--load run-tests.lisp
______________________________________________________________________
Makefile does depend on tabs, so the expanded file would be completely wrong.
Finally, for some reason, each expansion ends up with a new line? Is
that some necessary feature that org-capture templates rely on?
Consider if I would to generate a file with a name expanded from a tempalte:
%(project-name).asd
%(project-name).asd
I have to call (string-trim ...) everywhere where I call
org-capture-fill-template. Can we remove that ending new line, or is
that expected in expanded templates?
In my personal patched version I don't untabify, and I do remove the new line.
Are there some Ert tests org org-capture?
We have Skeleton and Tempo/Tempel as alternative, but they are extremely
clunky since they depend on custom DSL and string
concatenation. Placeholders, as seen from example are much nicer
alternative.
Now, I haven't used this extensively yet, but hopefully this gives idea
that org-capture template can become useful in a broader context, and
how we could do more with just built-in stuff, with less external tools
and less various other languages. For example for cookiecutter you would
use perhaps Python to run hooks, JS to define the template variables,
and their notation, {{ }}, for templates.
Sorry for the long mail, just trying to explain the motivation behind
this and what the patch would enable, or rather to say, make easier,
basically for free, since the patch is actually quite simple.
0001-Make-org-capture-fill-template-take-optional-evaluat.patch
Description: 0001-Make-org-capture-fill-template-take-optional-evaluat.patch
