>> I think you could relax there the requirement, and use princ under the
>> hood, instead of insert in org-capture-expand-embedded-elisp, without
>> introducing backward incompatibility. Since org-capture-fill-template is
>> always printing to a buffer, and return buffer string, it should be OK
>> to do. There is no reason to enforce string in %(). Just a suggestion.
>
> Do you mean %(variable-name) should expand to its value and
> %(function-name) should expand to function call result?
> If yes, what about %(temporary-file-directory)? Should it call a
> function? get variable?
No, not at all, it would be impossible to implement correctly. I was
perhaps a bit too fast and jumped over details, and didn't explain
myself well.
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 :).
>>>> 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.
>>>
>>> I asked you to open new threads for a reason. Mixing too many things in
>>> the discussion will just create a mess. For context, I actually believe
>>
>> I understand that; I am just not interested in long discussions on Emacs
>> mailing list. Forgive me, been there done that. If it wasn't of the interest
>> to
>> add this extra patch, and org-capture would continue to be used just for
>> shorter capture templates as it is used by now, than it is not a problem.
>> Even if I agree with what you say later on that it is a bug, and that was my
>> intention to say too, it is probably not important, so lets not engage in
>> long
>> discussions 🙂. That was the reasoning.
>
> If your intention was not reporting a bug but supporting your patch, it
> is not fully clear to me what exactly you are asking for. The patch you
> proposed in this thread does not do anything about untabify and newline
> issues; it just allows custom %(...) template expansion.
No, it does not, but if the patch is not interesting, than untabify and
newline thing, are not very interesting to change. Since nobody has
complained about them, and people are not using org-capture templates
in the way that matters.
>>> that unconditional untabification is simply a bug -- consider code
>>> blocks in template that are in python. Stripping tabs will be an error
>>> there. Similar for a new line. Regardless what we decide about changing
>>> template syntax for Elisp expansion, these bugs need to be fixed. That's
>>> why I asked to open new threads.
>>
>> That is my stand about untabify. As you say Python, and for example as I
>> tried to illustrate Makefiles. I am not sure it is worth much
>> discussions there tbh, and it is easier for you to just comment away
>> that line than to apply a separate pacth if I or someone else would to
>> send it in.
>>
>> For the newline at the end; the author explicitly say they want it, in a
>> comment, so I am not equally sure if it is a bug or not. I don't
>> understand though why they need it. Might be due to how they use
>> expansions elsewhere in org.
>
> I am confused. Is your intention here is to continue discussing these
> bugs as bugs now? (That would make this thread longer, so I feel that I
> miss something).
No. I was just reflecting over it, for the sake of being polite, since
you talked about it further.
>>> Let me provide a more accurate link:
>>> https://github.com/progfolio/doct?tab=readme-ov-file#keyword-expansion
>>> The %{keyword} syntax from doct is pretty close to what you are talking
>>> about. Please check. It may be a better way to address your request.
>>
>> Aha. Ok, thanks. As said I haven't study it, just glanced over it. The
>> reason I suggested my patch was because I use org-capture to implement a
>> little "project capture" framework, so I am already using it. It would
>> be a minimal addition since org-capture already does something
>> similar and I would not need to use a third party library.
>
> Before considering patches, I feel like we need to discuss what exactly
> we are trying to solve. For now, I feel like we have several things at
> hand.
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.
>>> If we were to consider the feature you are asking for, I'd go for
>>> something closer to doct keyword, maybe allowing %{keyword} to refer to
>>> %{elisp-variable} is :keyword is not defined in the template. WDYT?
>>
>> I agree. As mentioned in the above paragraph, I implemented something
>> similar already. I saw the glass as half full rather than half empty,
>> and took the opportunity to scale away anything I didn't need. For the
>> same reason, to avoid possible confusion I have chosen to use "$" as the
>> placeholder symbol. Basically I need just $() to eval lisp, but I have
>> kept $[], $<> and introduced also ${} as a shortcut for environment
>> variables. I haven't had time to test extensively yet, due to hollidays
>> and family time.
>>
>> I have attached my new little framework as a curiosa; still WIP. I am
>> happy to get critique and suggestions if anyone is interesting to take
>> a look at it.
>
> 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.
I had to fix it a bit yesterday, it was a misstake to copy elisp syntax
table, I am not using an emopty one and am using forward-list instead of
forward-sexp; and things seem to work the way I need them.
(template-fill "${HOME}") => "/home/arthur"
(template-fill "$(user-full-name)") => "Arthur Miller"
(template-fill "$((+ 2 3))") => "5"
(template-fill "$('(+ 2 3))") => "(+ 2 3)"
(template-fill "\\$((+ 2 3))") => "$((+ 2 3))"
(template-fill "$<%Y-%m-%d %H:%M>") => "2026-01-02 07:47"
I considered using $|| instead of $() as a placeholer, but I think I'll
keep $() since I don't consider placeholders as part of the passed
expression.
Sorry if I am too confusing. If it is of interest to extend the
org-capture-fill-template, as suggested in the other patch, I am happy
to help. In that case I guess it is better to continue in the other
thread, and we can also than make new threads for untabify and new line
at the end if its needed.
