In 5.1.5 we switched to using `<$action-setfield>` instead of
`<$fieldmangler>`. The problem was that in the process we lost the
validation of field names, making it possible to create fields with
illegal names
Fixes#1186
Cecily and Zoomin story views use a document.body that is smaller than
the document.documentElement. We were just clearing the popups on
clicks on the document.body Clicks on the document element (ie, on the
background of the page) were not being trapped, meaning that you
couldn’t dismiss a popup.
The `EditTextWidget.prototype.fixHeight()` function was defering its
work with `nextTick()`, which led to flickering on all browsers when
typing triggers a resize.
New export button appears as a page control toolbar button, a tiddler
toolbar button, and a button in the advanced search filter tab.
Initially supports exporting as static HTML, CSV, JSON or `.tid` file.
Still to do:
* Made the exporter descriptions translatable
* Hide the export button by default
* User docs
* Cleaning up the existing templates (eg,
`$:/core/templates/alltiddlers.template.html` should work by
transcluding `$:/core/templates/exporters/Static`)
* Docs for the new macros `exportButton`, `csvtiddlers` and
`jsontiddlers`
Issues:
* OS X Numbers refuses to open CSV files that have been generated in
Chrome, because it thinks they’ve been downloaded from the Internet.
Firefox works OK
* The export button won’t work within the tiddler info panel, or from
the *more* popup (this is because we don’t support nested popups)
Now the `tm-download-file` and `tm-save-file` messages use the hashmap
to specify variables to be applied when rendering the tiddler.
We also add a convention that the variable “filename” is used to
specify a filename for the download.
If the target tiddler of the draft is missing (as happens after
clicking “new tiddler”), then we count the draft as modified if the
text is not empty.
Also we count the the draft as modified if the draft title has been
changed
@felixhayashi I’m afraid I haven’t used your pull request as there were
a few details that I wanted to do differently. The main change is that
these changes allow both a param string and hashmap to be specified.
In 5.1.3 we introduced the idea that the `event.param` variable could
optionally be a hashmap, allowing multiple values to be passed with the
message.
This change moves the hashmap to a separate `event.paramObject`
variable, allowing us to pass both a hashmap and a param string.
