>>> No. What I meant is %:some-variable. (I have to say that I prefer my
>>> option 1 over this)
>>
>> Ah, I see. Sorry I missunderstood you there. I am not familiar with doct,
>> and I still didn't looked at it. Other stuff took precedence.
>>
>> Yes that would work. You could have %:some-var, and use %() for
>> functions, and leave out %{} for something else, and just mention
>> %:some-variable as a convenience to not have to type %(eval
>> some-variable). I think it would work nicely from the "cognitive pov",
>> for the users to understand and use. But it does complicate the parser.
>
> Not only that. I think I need to clarify my intentions. I am not looking
> to accept something that *only* adds an ability to refer to variable in
> capture templates. What I would find a useful addition is something more
> featureful. That's why I am bringing up doct and suggesting the new
> feature (if implemented) to include some of the doct functionality *in
> addition to variable expansion*.
You have been clear in the first one too, I did understood what you mean
:). I am just not sure how much extra functionalty you would like. If
you only want that "keyword" thing, as said I think it is possible with
%: notation.
I was more thinking about how users percieve the framework. It is
probably easier to just say, "a shortcut notation" %:some-variable for
%(eval some-variable) than to explain entire new placeholder perhaps? I
forgot to mention last time, you also skip the :full-lisp t property,
even with %:some-variable. I prefer it too for that reason. I wasn't
really happy with :full-lisp myself, but it was an easy way to switch
between parsers.
For the doc/manual string, I would prefer to be explicit about saying:
"If you want to insert a variable value, you have to use a function to
obtain the value, for example %(format "%s" variable) or %(eval
variable). In the latter case, the variable has to contain a value of
string type."
I think it is preferrable to assume that people are stupid just as I am
and write doc strings and manual so that that even Winnie-the-Pooh can
understand it. ELI5-me please, and you wil never hear from me
complaining :). I prefer simplicity and explicitly spelling out possible
corner cases and limitations rather than things not being spelled out and
being arcane. As a matter of fact that is what I often find arcane with
Elisp, in my personal opinion, Elisp API is full of land-mines just
waiting for someone to tramp on them. You don't need to agree me, but
that is my personal opinion. I don't think it has to be so.
Anyway, sorry for the rant, back to doct, :keyword seem to be a outside
of the template too. If you don't want :keyword to end outside of the
template, like my :full-lisp, than something like %{} would be
preferable. Than one can't just use read on the string, but has to parse
tokens in %{} separately, i.e. write a parser, but its not a big problem
I think.
>>> And do note that I do not propose %{} to be "almost same kind of
>>> template as %()". What I am really proposing is making %{} more powerful
>>> than $() - not only %{variable-name}, but also
>>> %{keyword-defined-in-the-template}, just like what doct does. See
>>> https://github.com/progfolio/doct?tab=readme-ov-file#keyword-expansion
>>
>> Ok. I understand. Unfortunately I didn't had time to look doct up. I am
>> sure it is awesome package on its own, I just never used it and am not
>> familiar with it. I took a quick look now when you have posted it.
>> It seems like it gives one the ability to declare custom escapes, or at
>> least it appears so. One can also seem them as local definitions I
>> think, similar to lexical variables introduced via let-bindings, since
>> (according to the doc), they take the precedence over built-in ones.
>>
>> I think you could have it with %:keyword as well. I am not sure, just
>> quick thought; than the usage would even resemble the declaration.
>
> Agree.
>
If you would to include something of these suggestion/brain-stormes
whatever to call them, what is the plan to procede? If you want I can
give you a bug-report to remove untabify and new-line and patches, or
can you or Max just add them yourself? Both are trivial, but some
wording about changes and potential incompatibilty for those (?) who
rely on that behaviour is needed, since they affect the end-user. Since
both are outside of "parsers" and affect the entire function and end
result, they can't be added as opt-in. Option is to add a new property
for each which I think is overkill, but we can discuss it if you want a bug
report for that.
Adding new parser, whichever it is, %: or %{} can be done relatively
easy I think. I am not sure TBH how much extra functionality you want,
so I don't know if I am the best person to help you, but at this point
in time I am quite familiar with org-capture-fill-template, I can try.
If you, Max or someone else have spare time, and can do it, it would
be appreciated, but since I have triggered this, I can at least try to
help with this.
