I’ve just found out the hard way that variable substitution are occurring within \define where they should not and not eleswhere and especially not within \procedure.
Hi @jypre variable substitutions like $(hole)$ are only performed within the body of a macro, and do not occur within procedures. (They are also used with the backtick substitution syntax, and the substitute operator).
In your macro example, the variable substitutions are performed before the macro is processed. At that point, the variables in question do not have values, hence the unexpected result.
Your procedure example doesn’t work because variable substitutions are not supported within procedures.
I hope this may help @jypre but also the community
I also find it helpful to spell out what I have learned as well.
Given procedures are now recommended over macros, initially discovering we could only reference parameters as variables, and not as variable substitutions as we do in macros, I was quite concerned at loosing substitution.
We do need to manipulate strings quite often, so substitution is critical.
although concatenation is often sufficient eg addprefix
However I quickly discovered, we have being more than compensated for this loss in procedures of substitution, in addition to the fact macros are only deprecated and integrate well.
With parameters as variables, they can be used directly as we may have done in the past with <<__paramname__>> (in macros only) now we can use <<paramname>>, however using parameters in filters offers much more functionality because ,of various operators that can manipulate strings. We now have;
the new substitute operator
existing filtered transclusion of course
functions as an alternative way to process filters, thus variable parameters.
this is very comprehencive I wont detail here but importantly there result can be used directly in text and you can join[ ] in filters.
The new back tick attribute values, including access to the substitution of variables and filter results.
one advantage here is you can avoid seperate macro definitions and evaluate, concatinate and substitute a value inline.
Another feature that helps us in the case of substitution is surprisingly the $parameters widget, because unlike with macros where we had the parameters in the definition macroname(p1:"") and limitations when calling <<macroname p1:"limits to what goes here"> the parameters can be defined with the parameters widget and have their (the parameters) values evaluated there eg; the parameter value can be derived from;
text references
functions
macros
filtered transclusions
new backtick attribute values
Special note on $parameters widget
Because using the parameters widget we can evaluate a value to assign to the parameter inside our procedures we can easily give tiddler names, fieldnames, variable names and more as a parameter, then have the entry in the parameters widget evaluate it.
\procedure myproc(fieldname)
<$parameters fieldvalue={{{ [all[current]get<fieldname>] }}>
fieldvalue for <<fieldname>> is <<fieldvalue>>
</$parameters>
\end myproc
<<myproc myfield>>
The point is we can convert a parameter to its value in the parameters widget, so our short form of procedure call <<<<myproc myfield>> is simplified.
We can also reuse the same variable name in the parameter widget eg use fieldname in the parameters not fieldvalue.
I have not yet established a naming or code pattern standard for these names rather than values.