Make macro parameters available as variables in wikified macros

[Jermolene]

Within wikitext macros, make the values of the parameters available as variables. Rather than overloading the parameter names themselves to be the variable names, we instead wrap the parameter name in double underscores. For example:

\define sayhi(name:"Bugs Bunny") Hi, I'm <$text text=<<__name__>>/>.

The advantage is that it helps to avoid situations where parameter values containing quotes can cause problems.

For example, consider this macro. It is intended to wrap a DIV around another macro invocation, passing through the single parameter to the inner macro:

\define related-tags(base-tag)
<div class="wrapper">
<$macrocall $name="anothermacro" param="""$base-tag$"""/>
</div>
\end

The code above will fail if the macro is invoked with the argument containing triple double quotes (for example <<related-tags 'Triple """ Quotes'>>). Using parameter variables offers a workaround:

\define related-tags(base-tag)
<div class="wrapper">
<$macrocall $name="anothermacro" param=<<__base-tag__>>/>
</div>
\end

[tobibeer]

the proposed triple single quotes may provide a more solid alternative. After all, two underscores are valid wikitext markup.

I would be more sympathetic to:

param=<{<foo>}>

[Jermolene]

Hi @tobibeer that's not quite how the proposal works. __base-tag__ is not wiki markup; it's a variable name. So it can't clash with wiki markup; the only risk is that it clashes with an existing variable name, hence the double underscore proposal.

[tobibeer]

I see, that being so I guess I would still shorten it to something like:

<<<foo>>>

maybe.

[Jermolene]

Hi @tobibeer my worry with re-using the parameter name as the variable name is the possibility of a clash. I have myself frequently written macros where the first thing it does is to transfer all of the parameters to variables of the same name. As ever, we need to retain backwards compatibility for everyone...

[pmario]

<<related-tags 'Triple """ Quotes'>>

do your users really use triple quotes? .. where?

[Jermolene]

do your users really use triple quotes? .. where?

The obvious example is the documentation macros for displaying examples. At the moment they use a hack for when we want to pass examples that include triple quotes, and there are many of them.

But it's deeper than that, I think. This fixes a horrible hole in the current macro implementation: the reliance on quoted text substitution.

[tobibeer]

If our macro examples require triple quotes, something ain't right about them, I would think.
Otheriwise, if we need just one more level, (triple) single quotes should do just fine.

[pmario]

If our macro examples require triple quotes, something ain't right about them, I would think.
Otheriwise, if we need just one more level, (triple) single quotes should do just fine.

I think the problem here is, that if you describe tripple quote use-cases, you have to use tripple quotes in your examples. ...

[pmario]

But it's deeper than that, I think. This fixes a horrible hole in the current macro implementation: the reliance on quoted text substitution.

Yea, ... For me it's ok.

[tobibeer]

I think the problem here is, that if you describe tripple quote use-cases, you have to use tripple quotes in your examples. ...

So, you have one example where you do things differently. I don't see a big deal about it. This adds a whole lot of variables to the widget stack for no good purpose, imho.

[tobibeer]

Or how do you use those variables in macros? <<__<<__foo__>>__>>? I really don't think we gain much, except increased complexity and a lot of overhead on the widget tree, for every single macro parameter.

[tobibeer]

I'm sure that for the one usecase where this helps, there is another way to go about it.

Plus, you can demo the triple single quote example using triple double quotes, apparently. Do you really need to demo both at the same time using some demo macro? I don't think so.

[Jermolene]

Or how do you use those variables in macros?

The variables are ordinary variables, and you use them in the ordinary way. The only special things about them are that (a) they only exist within the scope of wikifying a macro and (b) the current convention of adding double underscores to uniquify the name. The double underscore convention isn't otherwise special; it doesn't change the parsing of attributes or macro calls.

I really don't think we gain much

What we gain is the ability to break free of the disadvantages of text substitution. The current situation is that (a) people have written lots of tiddlers containing macros that contain triple double quotes because of the limitations of text substitution and (b) some macros randomly fail if passed parameters that contain triple double quotes. That means that there is already a bunch of macros out there that can't be used with certain tiddlers.

I think I've written elsewhere that I believe that text substitution based macros were a mistake in TW5, primarily because of the impact they have on parsing, but also because it can be very hard to debug mistakes. This new feature fixes things (in a backwards compatble way).

The next step is to extend the feature to transclusion, so that one can pass parameters to a transclusion, and access them via variables. All of this is part of the process of diminishing the distinction between macro calls and transclusions -- again, if I was starting TW5 today, they would be the same thing...

[tobibeer]

@Jermolene: I'm sure at some point it will click as to what this really does. Most importantly, it appears to help do away with quotes to defien attribute values.

For now, I just hope that we're not overloading some "variable namespace", e.g. I remember the dumpvariables Macro and I imagine that a lot of __vars__ will pop up now as a result of this change.