Dynamic parameters for macro/procedure/function calls

[Jermolene]

Introduction

This PR makes an important change to the handling of macro calls by finally allowing parameters to be specified as dynamic transclusions instead of just constant strings.

In other words, by changing the usual colon into an equals sign it is now possible to do things like this:

<<mymacro param={{Something}}>>

Or even this:

<div class=<<mymacro param={{Something}}>>>

Not to mention this:

<div class=<<mymacro param={{{ [<myvar>addprefix[https:] }}}>>>

We can even specify parameters for the inner call:

<div class=<<mymacro param={{{ [<innermacro p={{Something}}>addprefix[https:] }}}>>>

I am pleased about this change for obvious reasons: it removes a long-standing irregularity from TiddlyWiki's syntax, and it adds flexibility and expressiveness that will be appreciated by all wikitext authors.

The reason I am embarrassed is that it has taken so long to address this issue, particularly as it has turned out that the implementation is not enormously complex. In mitigation the changes in v5.3.0 laid a lot of the groundwork for this change.

Background

In fact, "macro calls" has become an increasingly ill-fitting term since v5.3.0 when the same syntax was extended to allow it to be used to invoke functions and procedures. I propose we use the term "call" to refer generally to all three formulations, and "macro call", "procedure call" and "function call" for the specific variants.

The call syntax can be used in three different settings:

• As a standalone construction
• As a widget attribute value
• As a filter operand value

In all cases, it is now possible to use an equals sign instead of a colon to allow parameter values to be passed as a transclusion, filter expression or nested call.

Backwards Compatibility

The backwards compatibility issues with this change are fairly extreme edge cases. In particular, previously a construction like this would have been interpreted as an unquoted parameter with the value "name=background":

<<mymacro name=background>>

So, this change will break code that invokes a macro with an unquoted parameter that contains an equals sign. There is no restriction on parameters with double or single quotes.

Progress

This PR is not yet complete:

• Documentation and railway diagram updates in "Macro Call Syntax" and "Procedure Call Syntax"
• Documentation updates for "Functions", "Macro Calls"
• Refactor "Improvements to Macro Calls in v5.4.0" into a consolidated example tiddler
• Enforcing new syntax to only work with equals signs (currently equals and colon are considered equivalent)
• Calls as attribute values
• Standalone calls

[netlify]

✅ Deploy Preview for tiddlywiki-previews ready!

Name	Link
🔨 Latest commit	b6a9152
🔍 Latest deploy log	https://app.netlify.com/projects/tiddlywiki-previews/deploys/69768bce7f80680008e98545
😎 Deploy Preview	https://deploy-preview-9055--tiddlywiki-previews.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

Confirmed: Jermolene has already signed the Contributor License Agreement (see contributing.md)

[github-actions]

📊 Build Size Comparison: empty.html

Branch	Size
Base (master)	2528.4 KB
PR	2534.9 KB

Diff: ⬆️ Increase: +6.5 KB

[Leilei332]

IMO #8732 can be implemented, which is less complex and is consistent with functions in filters.

[pmario]

@flibbles -- I think this one will have side effects on "relink plugins". Did you see this PR? Can you have a closer look. -- Just in case.

[flibbles]

It will have an effect on Relink, and Uglify. But I do see the value in making parameters and attributes more analogous. (Just wish we could get rid of the old way of doing things so we didn't have so much legacy syntax to support.)

I'm not sure how I feel about that block syntax though. Would that work within attribute invocations or operator parameters? It seems like it would be pretty ugly to me.

If you want blocks for macros, which I imagine is a rare case for pre-existing macros, couldn't someone could just use the <$transclude widget to call a macro with blocks. That could even apply to the tabs macro as we have it today. Backward-compatible.

I know I've been using blocks pretty heavily while I write TW5-Graph, but that's why I pretty much fully adopted the \widget pragma.

[pmario]

I think the "block parameters" are just an idea. I think they are not part of the PR at the moment.

I am actually not sure, what it should be used for. In the end users will need dynamic text there. Which will make every thing complex again. IMO for real world projects a title-list and tiddlers is the way to go in the end.

[github-actions]

📊 Build Size Comparison: empty.html

Branch	Size
Base (master)	2448.3 KB
PR	2453.9 KB

Diff: ⬆️ Increase: +5.6 KB

---

✅ Change Note Status

All change notes are properly formatted and validated!

📝 $:/changenotes/5.4.0/#9055

Type: enhancement | Category: hackability
Release: 5.4.0

Dynamic parameters for macro/procedure/function calls

🔗 #9055

👥 Contributors: Jermolene

---

📖 Change Note Guidelines

Change notes help track and communicate changes effectively. See the full documentation for details.

[Jermolene]

@linonetwo I disabled the Serialize/Attribute wikitext test because it is broken with the changes in this PR. Presumably the serializer needs to be updated to understand the new syntax? If you are able to fix it, could you propose the changes here? Many thanks

[linonetwo]

Sure, let me PR to this branch, that is easy for me (or Claude4.5, but I will review it)

Need to add more information in parser, so serializer could know how to deal with them. So it gradually become CST instead of AST I think. That is why I have to modify core to add serializer, instead of let it be a 3rd party plugin.

[Jermolene]

Sure, let me PR to this branch, that is easy for me (or Claude4.5, but I will review it)

Thanks @linonetwo

[linonetwo]

#9459

[saqimtiaz]

@Jermolene reviewing the to do list for this PR, I think this can be merged for v5.4.0 as the main functionality is in place and and it represents a signficant step forwards in terms of usability.

The only item that really should be implemented for this release is " Enforcing new syntax to only work with equals signs (currently equals and colon are considered equivalent)". All the others, like comments within widget attributes were only added to the to do list for this PR since they touch the same parts of the code, but are otherwise not connected.

[Jermolene]

Thanks @saqimtiaz, I agree that it would be good to get it in. I'll have a look at the colon/equals sign issue.

[pmario]

@Jermolene -- slightly OT -- ESLint specific info.

It is possible to allow console.log() at indent level 0. So it stands out in the code. We could extend the "indent" rule, so it does ignore console.log() indentation by default.

[Jermolene]

It is possible to allow console.log() at indent level 0. So it stands out in the code. We could extend the "indent" rule, so it does ignore console.log() indentation by default.

Hi @pmario I think that there are so few situations where JS code should include any console.log calls that I wonder if we should actually flag any use of it in new code.

[Jermolene]

The only item that really should be implemented for this release is " Enforcing new syntax to only work with equals signs (currently equals and colon are considered equivalent)". All the others, like comments within widget attributes were only added to the to do list for this PR since they touch the same parts of the code, but are otherwise not connected.

Done in a29ae90 and 8ebf052

[saqimtiaz]

Great, thanks @Jermolene.

I will create issues for the deferred items like comments within filters and widget attributes.

[saqimtiaz]

I believe we are only missing updated documentation now.

[Jermolene]

I believe we are only missing updated documentation now.

I've updated the OP to identify the required docs updates - it is the railroad diagrams that will be a bit of a nuisance.