>>> 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)
>>>
>> ...
>> 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).
>
> I believe that %() + :full-lisp is worse. Simply because %{} is clearly
> different from %()
I would say it is just slightly different. Both eval embedded lisp; that
is the base. The one does a bit more (full lisp), and thus asks the user
to type a bit more too and sign up for a contract, if that is some sort
of reminder. But of course, at the end it is always individual what one
finds more clear.
> different from %(), while :full-lisp will be located away from the
> template element and may be overlooked.
I agree with this. However, this function is rarely used on its own. Not
even I use this directly, but have a framework in which I use it. If you
think of org-capture templates, in that context it will be part of the
capture template, exampelwise:
'("c" "common-lisp-project"
plain #'some-file-generating-func
"template"
:immediate-finish t :full-lisp t ...)
But if some sort of org-capture-fill-template is used explicitly, than
yes, as you say it is a outside of the template itslef.
Use which ever you prefer, I am just trying to provide some extra input
for the thought.
>> 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.
>
> 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.
>> 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.
>
> "already very close" is exactly what I believe is a potential source of
> problems.
I understand how you think. We are not in a disagreement; however it's a
tradeoff. Both solutions are tradeoffs. Designing programming languages
and APIs is difficult. Here is an example why.
> 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.
