Global variables access within attributes will automatically trigger a refresh if the attribute text changes, but that wasn't happening for transclusions.
The objective is to add a $depth attribute so that it is possible to reach up to retrieve the parameters of ancestor transclusions. However, doing so requires changing the encoding of parameter names so that it is not possible for a user parameter to clash with an attribute like $depth. So now we have to double up dollars on any attribute names seen by the parameters widget, just like with the transclude widget itself.
Can invoke any functions, not just those start with a period. And can pass zero parameters (in contrast when invoked as a custom filter operator there's no way to omit the first parameter).
So far it appears to be totally backwards compatible... In practice, I think maybe this and the conversion of the other macros should go into a separate subsequent PR.
The basic idea is that if we don't find a variable `foo` then we fallback to retrieving the value from the tiddler `$:/global/foo`, if it exists.
This allows us to replace the usual importvariables-based mechanism for global definitions, avoiding cluttering up the variable namespace with every macro.
In order to permit subprocedures to be overridden, we also introduce a mechanism for conditional definitions: preceding the word definition|procedure|function|widget with a + causes the definition only to occur if the specified variable doesn't already exist. In the next commit we'll apply this mechanism to the tabs macro
* Fix for Bug #6618
This Commit fixes Bug #6618. It is a little bit more complicated than
using one tiddler to store the new value for a field. Because the
following can happen:
* The user types "not-a-date" into the field value of a simple text field.
* The user now selects a field name that uses a HTML5 date editor. The
Editor will show no date because the value cannot be parsed.
* The user saves the tiddler by clicking the checkmark.
Now the date-field contains the value "not-a-date" but the user was not
aware that this will be added. The edit control showed no date (because
the value was invalid) and the user assumed the field was empty and
won't be added to the tiddler.
To prevent this, every kind of field editor gets its own storage tiddler.
Its name is derived from the SHA256-hash of the name of the tiddler that
is returned by the Field Editor Cascade. That way every editor in the
cascade is only seeing its input. As long as the default setup (with one
default editor) is used, everything works like in 5.2.1.
This commit also fixes the bug that the after adding a field the
field-type input box was not focused again.
* Update Documentation for Field Editor Cascade
The fix for bug #6618 makes the handling of the tiddler backing the edit
operation much more complicated. See previous commit "Fix for Bug #6618"
for more details.
* Fix: eventcatcher widget - variables can be undefined
* Fix: selectedNode can be an svg where offsetLeft ... are undefined
* Make check for offsetLeft short
* remove second collectDOMNodeVariables
* Fix lazy all template with user defined macro cause error
Fixes https://github.com/Jermolene/TiddlyWiki5/issues/6637
* fix: exclude the SJCL library when saving
@Jermolene said:
The construction -[type[application/javascript]library[yes]] is used in the core as a rather clumsy way to exclude the SJCL library when saving. The same construction is in the usual $:/core/save/all filter too.
It's possible that we should review unintended side effects of that behaviour, but here we should leave it alone.
There are two big changes here:
Replace the previous "ts-wrapper" mechanism, which we had been using to redefine custom widgets inside their definitions to prevent recursive calls. Now we've got the genesis widget we can instead control recursion through a new "$remappable" attribute that allows the custom widget mechanism to be skipped.
We also extend the slot widget to allow a depth to be specified; it then reaches up by the indicated number of transclusion widgets to find the one from which it should retrieve the slot value.
* Documentation for indeterminate checkboxes
* Unit tests for indeterminate checkboxes
* Implement indeterminate checkboxes
* Simplify indeterminate checkbox example
* Slightly simplify refresh logic for indeterminate
That five-line if statement can be turned into a simple assignment.
* Use "yes" and "no" for checkbox indeterminate attr
This makes the "indeterminate" attribute of the checkbox widget work the
same way as other boolean attributes of other widgets.
* Fix bug with invertTag attribute
One place in the checkbox widget code was checking invertTag for
Javascript truthiness rather than the value "yes", which could have
produced incorrect results if anyone wrote invertTag="no". Fixed.
