arthur miller <[email protected]> writes:
> What I meant with "relaxing demand and using princ", was that instead of
> this:
>
> (cond
> ((not result) nil)
> ((stringp result) (insert result))
> (t (error
> "Capture template sexp `%s' must evaluate to string or nil"
> sexp)))
>
> in org-capture-expand-embedded-elisp, use princ to print to buffer
> instead of (insert result). Becuase currently (eval variable) or
> (identity variable) only works on strings, i.e. variables that hold
> string value. Thus user has to ensure the variable is printed to string
> themselves, via prin1-to-string or something similar. If you would to
> use princ under the hood to insert the value into the temporary buffer,
> than users can use any value, numeric, characters etc.
>
> In theory, it should be backward compatible, since the current mechanism
> inserts a string into the temporary buffer and than returns buffer
> string as a result; it is already "stringifed" so to say. But org is big
> and being around for a while, so there is always a chance I am wrong :).
I am not against such addition.
For numbers, it makes sense.
One slight concern can be that erroneous targets that, say, attempt to
insert a buffer may be harder to catch.
Another possible downside is that we lose the intentionality of the
output - (princ ?X) is "88", not "X". But maybe it is justified for
purposes of template simplification.
> My original proposal was to make org-cpature-fill-template a bit more
> general and useful in other contexts, as seen from the examples, for
> text/code generators and similar. I fill that is somehow very close, but
> not exactly there as of current implementation. The biggest problem is
> the %(variable) thing, because it is awkward to repeat oneself. If that
> is of interest, I am open to help with the patch, and in that case
> propose patch to untabify and fix newlines too, because in that context
> they are problem too. In that case, we can continue in the other mail I
> sent, with the second patch proposal. Or if someone has a better
> proposal, I would be happy, to help too.
Ok. For %(variable), I do not like the idea of custom variable or
capture template to alter the interpretation -- I believe that
conditioning semantics on customization is potentially confusing.
I have two alternative suggestions instead:
1. Follow the idea from doct with new %{keyword} element, but
allow keyword to be (1) :keyword from template definition; (2)
variable; (3) A function call %{(function-call ...)}.
2. Extend the existing %:keyword placeholder - we may not only accept
link info there, but also :keyword from template definition + allow
(... :keyword1 'variable-name :keyword2 (lambda () ...) :keyword3 value)
>> Could you please explain what your framework is trying to achieve?
>> I can see that it (1) gets rid of org-capture behavior when %[...] can
>> be expanded inside %(...); (2) changes %(...) to demand full sexp inside
>> - %((...)) for function call; (3) adds ${ENV}.
>> Is this framework trying to replace org-capture-fill-template? Do
>> additional expansion before? After?
>
> That little framework let me use $[] and $() similarly as I would use
> %[] and %() without the problematic behvaiour in %() regarding variable
> evaluation. That is basically all I need. ${} and $<> are just a little
> bit of sugar on top. It is not uncommon to use dates and time in code
> generators, so they might be useful to keep.
>
> Yes, your (2) does holds, it does ask to eval full lisp as $((+ 2 3)).
>> Is this framework trying to replace org-capture-fill-template?
>
> Yes. It replaces it completely for my part. Does not use org-capture at
> all for template expansions. I still ose org-capture for something else,
> but will use this one for template expansions in my personal code gens.
Ok. So, I conclude that it is not intended for upstreaming.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
