>> What t I meant with "relaxing demand and using princ", was that instead of
>>
>>
>> (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.
Sure, that is valid. However, what is the damage? One would get a printed
representation of an object, say "#<buffer *scratch*>", instead of the
content. Those things should be catched anyway during the development. But
I agree it is a bit of a trade off there. If this was a code that does
something to hard drive, or sends something to a process, something were
more damage can be done, I would not accept such trade off myself.
> 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.
That is true, one would have to use char-to-string in that case. I have no
opinion if that is too problematic or not.
>> 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)
>
All three options, mine that suggest altered %(), and both of yours are
trade offs. As everything else in life seems so.
Mine idea is that %() uses parentheses which is well, somehow associated
with Lisp. By using :full-lisp keyword, one explicitly signs up on
somewhat altered meaning. The meaning itself is not radically altered
either.
When it comes to confusion, I thin both mine and yours 1. open for some
confusion, or at least will be questionable by an end-user who will
wonder "Wait, both do the same as the old one %(), why do we need this
one now?" Regardless if it is spelled ${} or %() with :full-lisp (or
some other keyword).
The option number 2., if I understand it well, will require me to type
something like %(:keyword3 some-variable)? That seems like
counterproductive to the proposal. The idea is to simplify usage, so I
don't need to repeat myself. But I am not sure if I understand it
correctly.
I think thinking about "confusion", is probably overthinking it? I
personally would rather use %() :full-lisp, because it is already very
close to what the original %() does, and reminds of lisp, and would
leave %{} "free" for possibly something more exciting in the future
instead of using it for almost same kind of template as %(), just
slightly different. Not that I have something more exciting for %{}, but
perhaps someone else will have one day. Cool to not burn the option for
that notation so to say. That is just mine opinion of course, I am not
an absolutist, just exchanging ideas and thoughts here.
>>> 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.
No, no, no, you don't want two frameworks doing almost the same. I was
just illustrating that I had the same opinion as you about using
different notation to avoid the confusion, if I write something from the
scratch. If I am gonna publish mine framework one day, and it is very
similar to org templates, than I will certainly use differnt notation to
not accidentally confuse the two. You said something like that, and I
illustrated, and I also illustrated I am OK if the addition to templates
is not acceptable. I am fine if org keeps to be as it is, but cool if we
can extend it and I don't need to keep my extras.
