>> If we document that (EXP), not EXP should be a valid expression, we are
>> good.
... actually we do. So, maybe docstring can still be improved further.
No to be a devils advoce, but I am not sure you do. If we look at:
‘%[FILE]’
Insert the contents of the file given by FILE.
‘%(EXP)’
Evaluate Elisp expression EXP and replace it with the result. The
EXP form must return a string. Only placeholders pre-existing
within the template, or introduced with ‘%[file]’, are expanded
this way. Since this happens after expanding non-interactive
"%-escapes", those can be used to fill the expression.
‘%<FORMAT>’
The result of format-time-string on the FORMAT specification.
example useage:
"%[~/repos/licenses/texts/plain/GPL-3.0]" => will insert a file from
~/repos/licenses/texts/plain/GPL-3.0
[] is not part of the xpression
"%<%y%m%d>" => "251220"
<> is not part of the expression
"%( user-full-name )" => your user name if it is defined
() **are** part of the expression.
That sort of breaks the symmetri too, or the pricniple of the least surprise.
And to reflect to the paragraph belov, how clear is it what is evaluated in
the last one? The variable, or the function, since both exist.
>> In practice it will make it least more clear why using a variable failes :)
>> It would be even better if the documentations spells out clearly: can't use
>> variables only functions. Anyway, that still means the usage in a bigger
>> template, like a file generator is more elaborate than needed. But if you
>> don't want it, so it is.
>
> Note that %(variable) can be ambiguous when variable is both a function
> and a variable. In sexps, it is not ambiguous - (foo) must always be a
> function call.
Both foo and (foo) are sexps. Foo is atom (symbol) and (foo) is list.
Function call would be %((EXP)) and variable %(EXP) to reflect that.
To add where I started above, with the current notation I don't find it clear
we are executing a funtion here, especially if I spell it the way I did:
%( user-full-name )
I am a bit of a devil's advocate with the spelling there, forgive me, it
is just to illustrate it more clear.
If we are consistent with %[] and %<> than %() should act same, and the EXP
is EXP and not (EXP). In that case it would be more explicit when function
is called:
%( user-full-name ) vs %( (user-full-name) )
That treats () as the marker, to delimit EXP from the surrounding text,
not as the part of the expression itself.
When I saw the code, to me this looks like clear logical error when it
was written. Unless the author really wanted to explictly forbid the use
of variables in %(). Since the docs does not mention it anywhere, and
the notation in the manual suggests that () is not part of the
expression itself, I draw the conclusion it is an error. Not to blame
anyone or anything, just trying to understand it.
> In theory, we may introduce another template element for variables, but
> I never heard about such a need from anyone... You can send a feature
> request marked [FR] if you want to get feedback. If enough people need
> such feature, it can be added.
It is OK. I perhaps asked too much from capture-templates, I can use
other template engine as well. I was bitten by this, I used
"project-name" to generate a template and wondered why does it say void
function :).
I was aware it would break the existing tempaltes which use this
feature, but my thought was that this is not widely used feature,
otherwise people would notice and fixed it earlier. But if you say it is
used frequently used than it's OK, I can live without it.
Anyway, as said, thanks for looking at it.
