Introduce "thisTiddler" variable

[Jermolene]

This PR introduces a new system variable called thisTiddler that is set to the title of the tiddler that contains the text of the widget being rendered.

For example, within a template, thisTiddler contains the title of the template itself, even if it has been invoked with a different value for the currentTiddler variable. This makes it possible for templates to robustly include references to data that is stored in their own fields.

Note that invoking a macro does not change the value of thisTiddler. This means that it can be used by macro definitions to access the fields of the tiddler from which the macro was invoked. This will work even if there are intermediate macro invocations.

There is currently no way for a macro to access the title of the tiddler in which it was defined. Part of the issue is that macros are not necessarily defined in a tiddler at all; they are implemented as variables, and so can be dynamically computed.

Backwards compatibility considerations:

• Will break some existing usages of a variable or parameter called “thisTiddler”
• Tiddlers that previously would have parsed to an empty parse tree will now produce a single set widget to set thisTiddler. This might break code that tests for an empty parse tree (this is no longer the case since the refactor in a61d644)

Thanks to @ericshulman for the inspiration.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
tiddlywiki5	✅ Ready (Inspect)	Visit Preview	May 6, 2023 10:43am

[Jermolene]

@ericshulman – I haven't added the docs for this yet. I wondered if you might be able to help with one or two examples that would be useful and instructive?

[pmario]

Will this make it possible, that we have predictable state-variables based on tiddler fields instead of needing to use "qualified states" which have unpredictable numbers?

[Jermolene]

Will this make it possible, that we have predictable state-variables based on tiddler fields instead of needing to use "qualified states" which have unpredictable numbers?

No.

What would that look like?

Those "unpredictable numbers" are because we hash long state qualifiers to make them easier to work with. There's no requirement to take that approach, but I don't think we have yet come up with an approach that is better while still being as general purpose.

[Jermolene]

Hi @pmario please could we move that question to a separate issue?