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
These improvements rely on the new JSON operators to be useful. Those improvements were originally in #6522 but now there's an updated version in #6666. Managing things is simpler if I merge these changes now
An experiment to try out using the new JSON operators for rendering the JSON parse tree that we get back from the wikify widget.
As usual with these experiments, this one is going to require quite a lot more work to finish up:
* The formatting is via direct styles rather than classes
* The formatting for attributes and properties is not yet completed
* The same thing needs to also be done to the widget tree preview
* feat: expose isMobile to info
* feat: allow access browser info from $tw.browser
* fix: adapt typo
* refactor: only export selected properties
Jermolene 5 hours ago
The trouble is that the properties of bowser.browser are not under our direct control, and so subsequent updates to Bowser might overwrite important properties of our own. I'd rather explicitly import the properties that we choose to support.
* refactor: put things into `is`
* 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.
