> I see that things are not yet clear for you. Any ideas how to make
Things are very clear for me. If it was only for me, you would not need
to bother at all. Thank you very much for the effort anyway.
> Any ideas how to make
> documentation more clear for you? (It is hard for me to improve further,
For me you don't need to do anything :-).
For others, if we are at it, I think it is much better to type
(princ default-directory) than (eval default-directory), if you gonna have
that example in a doc string or manual.
It is always better to use less force than more so to say. Not that it
makes things much better; those templates are evil anyway. They use
org-eval, which calls eval under the hood, so in theory any template
that calls %() or %[] can do anything. But still, it is probably more
clean to use (princ var) than (eval var) at least in Emacs manuals. Do
what you want with it.
Also, while the example gives an example of how to use a variable, what
I said from the beginning, would be good to state that explicitly in the text:
"If you need to use variables, you have to wrap them in some function call,
i.e. (princ var)",
Or something similar. I am not very good with the words unfortunately,
so I am sorry I can't give you a better wording. But that was what I had to
"discover", what wasn't clear for me from the beginning. Perhaps it is just
me.
> because I never saw the current way documentation explains things as a
> problem to start with).
Neider did I, until I wanted to do something more interesting with it than
one-liner capture templates.
>>> 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.
>> ...
>> 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.
>
> I am open to your patches, as long as some more people find them useful.
We have seen it was more interesting to point out which doc string I
refer to, than to reflect over anything else I said, so I guess it
is not very popular demand, which is of course ok as well :).
>> 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: ...
>
> Can you please open a new thread for this?
>
>> 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?
>
> Maybe. Again, could you please open a new email thread?
>
>> In my personal patched version I don't untabify, and I do remove the new
>> line.
>> Are there some Ert tests org org-capture?
>
> Yes, there are tests. testing/lisp/test-org-capture.el.
Ok. Thanks.
>> 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.
> Have you seen https://github.com/progfolio/doct ?
I did a web-search after you mentioned it previously and found Nicholas
package. But I haven't had time to study it, just glanced over the
readme. What is with it? As I understand he introduces different syntax,
at least what README says. I have no idea if it adds more capabilities,
if he has a different implementation completely or if it runs on the
existing org-capture.
I don't introduce any new syntax, I am just trying to fix a fundamental
flow, which shouldn't be there from the very beginning to make the thing
easier to work with. In like ~50 sloc, no additional libraries needed.
That would make writing bigger templates, like entire files easier
and less clunky, as shown with attached example. I can buy it is not
interesting to other people, so it is fine :).
My misstake was to suggest a backwards icompatible patch first, sorry
for that. But the second one was completely unobtrusive.
Anyway, thank you for your work, and for clarifying the doc strings.
About opening other threads: nobody has answered on the other one, so I
guess opening more threads is not best use of the time and energy,
neither mine nor yours.
Best regards.
