arthur miller <[email protected]> writes:
>>> (cond
>>> ((not result) nil)
>>> ((stringp result) (insert result))
>>> (t (error
>>> "Capture template sexp `%s' must evaluate to string or nil"
>>> sexp)))
>> ...
>> 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.
>
> 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.
It probably is not.
>> 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 %(), while :full-lisp will be located away from the
template element and may be overlooked.
> 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)
> 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.
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
--
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>
