This might require a lengthy explanation, there’s really a lot going on here.
Starting with the original get macro:
\define get(pre,str,suf)
<$list filter="[prefix[$:/prefix[$pref$]regexp[$string$]suffix[$suf$]]" variable="item"><$transclude $tiddler=<<item>>/></$list>
\end
Given your two tiddler names $:/my/button/standard and $:/my/icon/delete-x, I think the second prefix after $:/ in the filter expression does not really belong there. Also, I changed the macro param names to pre and str:
\define get-1(pre,str,suf)
<$list filter="[prefix[$:/$pre$]regexp[$str$]suffix[$suf$]]" variable="item"><$transclude $tiddler=<<item>>/></$list>
\end
This can be rewritten into a procedure (like in your previous posting):
\procedure get-2(pre,str,suf)
<$list filter=`[prefix[$:/$(pre)$]regexp[$(str)$]suffix[$(suf)$]]` variable="item"><$transclude $tiddler=<<item>>/></$list>
\end
There is a catch, though. Macros and procedures cannot always be used interchangeably. Here is where it gets somewhat complicated.
First, it’s helpful to understand what the get-1 macro and the get-2 procedure expand into. They both do not directly yield the content of the tiddler whose name matches the prefix, string, and suffix. Instead, they both expand to the WikiText code that will resolve to the content of this tiddler when things are finally being rendered. The macro just substitutes its parameters a bit earlier, and since this substitution happens in a textual form and occurs before the body of the macro is wikified, unsanitized parameters can cause problems further down the line. This is one of the reasons why macros have been deprecated and procedures were introduced (another reason is that procedures improve performance).
There are some subtle semantic differences between macro calls, procedure calls, and function calls, all of which use the same easy to remember <<...>> shorthand notation. Function calls are special in one particular way, as their results are transcluded as plain text (macros and procedures are wikified when transcluded).
More importantly, these three transclusion forms should not be confused with variable attribute values, which use a someAttribute=<<...>> syntax and which are only allowed in tags (including in widget tags). Variable attribute values also behave differently depending on whether their variable has been declared as a macro, procedure, function, widget, or simply as a variable. For example, btn-icon in:
<$let btn-icon=<<get my icon x>>>
<<get my button standard>>
</$let>
… will be either set to the following text when get has been defined as a macro (see get-1):
<$list filter="[prefix[$:/my]regexp[icon]suffix[x]]" variable="item"><$transclude $tiddler=<<item>>/></$list>
… which is totally fine. But the variable will be set to the following text when get has been defined as a procedure (see get-2):
<$list filter=`[prefix[$:/$(pre)$]regexp[$(str)$]suffix[$(suf)$]]` variable="item"><$transclude $tiddler=<<item>>/></$list>
This then turns into a problem during rendering, because the parameters pre, str, and suf haven’t been substituted by their values in the returned string, and their values went out of scope the moment the procedure call concluded, but before the returned string of the procedure’s body has been wikified and rendered. When the content finally does get rendered, the list widget will see the filter [prefix[$:/]regexp[]suffix[]] with the three missing variables having been reduced to empty strings. This incomplete filter expression will cause the list widget to iterate over all system tiddlers.
I’m going to assume that you only use the list widget to evaluate the filter expression to a variable, and not to transclude multiple icons into one button. To limit the number of iterations to just one, you could add a first[], last[] or limit[1] at the end of the filter expression.
The multiple iterations of this list widget are not likely to be the cause of the recursive transclusion however; this error only shows up when a tiddler directly or indirectly transcludes itself, e.g. like so:
<$transclude $tiddler=<<currentTiddler>>/>
It’s not really obvious to me where exactly this recursive transclusion happens.
The <$list> widget is not really necessary when get-1 and get-2 only need to transclude one tiddler for the icon, and one tiddler for the button. The procedure can be rewritten without a list widget:
\procedure get-3(pre,str,suf)
<$let pre=`$:/$(pre)$`><$transclude $tiddler={{{ [prefix<pre>regexp<str>suffix<suf>] }}}/></$let>
\end
This is both simpler and a bit safer. But as before, this version only yields WikiText, with the <$transclude> widget still being part of it. The transclude widget would only be reduced to the actual tiddler content when everything is wikified and rendered.
However, rewriting get-3 into a function would allow obtaining the content of a tiddler in a more immediate way:
\function get-4(pre,str,suf,field:"text")
[is[system]removeprefix[$:/]prefix<pre>regexp<str>suffix<suf>addprefix[$:/]get<field>]
\end
This version is more in tune with variable attribute values, but less optimal when the results need to be wikified (since functions are transcluded as plain text). A temporary btn variable can be used so that the text from the function gets wikified as HTML output:
<$let btn-icon=<<get-4 my icon x>> btn=<<get-4 my button standard>>>
<<btn>>
</$let>
If your’re going to use procedures combined with variable attribute values instead, your call site needs to be rewritten to:
<$wikify name="btn-icon" text="<<get-3 my icon x>>" mode="inline" output="html">
<<get-3 my button standard>>
</$wikify>
Hope that made things a bit clearer.
