This PR extends the handling of macro/procedure/function invocationsmade via the <<..>> shortcut syntax to allow dynamic parameters instead of just static strings. To indicate the new syntax the colon that usually separates a parameter name from its value is replaced by an equals sign. For example:

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

Note that the new syntax obviates the need for <$transclude $variable=...> constructions in many cases.

The extended syntax allows parameter values to be passed as transclusions, filter expressions or nested invocations in three settings:

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

See Calls for more details and examples.

This PR introduces a new filter run prefix :let that assigns the result of the filter run to a variable that is made available for the remaining filter runs of the filter expression. It solves the problem that previously it was impossible to compute values for filter operator parameters; parameters could only be a literal string, text reference or variable reference.

This PR also introduces multi-valued variables, the ability to store a list of results in a variable, not just a single string. They can be assigned with the new :let filter run prefix, or the existing <$let> widget. The full list of values can be retrieved using round brackets instead of the usual angle brackets. In all other contexts only the first item in the list is used as the variable value.

• Multi-Valued Variables
• Let Filter Run Prefix
• LetWidget

Introduces Background Actions that are triggered whenever there is a change to the results of a specified filter.

Building on that, it also introduces a new Media Query Tracker Mechanism that can track the results of any CSS media query (not just dark mode), storing the results in a shadow $:/info/... tiddler

These improvements were cherrypicked from #8702 - Colour Handling Improvements when it was deferred until v5.5.0.

This is an internal change that will only be of direct interest to plugin developers but will form the basis of future user-facing features. For example:

• Programmatically manipulating wikitext content by modifying the syntax tree and deserializing it back to wikitext
• Building WYSIWYG editors
• Creating WikiText formatters and linters