Typically for JavaScript, initialising an object as an array doesn’t
break anything because an array is an object. Anyhow, it should be an
object in this case.
It thereby reduces code complexity that would arise when setting
many variables using "<$set>".
```
\define helloworld() Hello world!
<$vars greeting="Hi" me={{!!title}} sentence=<<helloworld>>>
<<greeting>>! I am <<me>> and I say: <<sentence>>
</$vars>
```
How this Widget differs from the set widget:
* Variables may be created by using the "key=value" notation
that you already know from widgets like action-setfield.
* You cannot specify a fallback ("emptyValue")
* You cannot use a filter to produce a conditional variable assignement
Original discussion that led to the creation of this widget:
https://github.com/Jermolene/TiddlyWiki5/issues/1610
Allow widgets to choose not to propagate actions. This is important for
widgets that themselves trigger actions.
Note that this change will cause problems with any existing
5.1.8-prerelease plugins that call `invokeActions()`.
The tabindex attribute was being set to the string “undefined” if the
attribute was not specified. The fix is to only set the tabindex
attribute if the attribute was specified.
They don’t get automatically decoded when the browser reads the
resulting HTML. So, instead, we’ll solve
1e9e1a1fdc by switching to double quotes
for attribute values.
* Moved “add new plugin” into a modal wizard
* Adopt big friendly buttons
* Add plugin icons and readmes to “add new plugin” modal
* Use tabs for splitting plugins/themes/languages
* Consistent styling between the “add new plugin” modal and the
“installed plugins” control panel tab
* Behind the scenes, moved from addressing the library as
`recipes/defaults/tiddlers/<etc>` to `recipes/library/tiddlers<etc>`
This may cause backwards compatibility problems for people relying on
the block mode parsing, but it’s much better for the rest of us as it
avoids an unsightly paragraph tag
Stop the logger from creating alert tiddlers on the server. They
propagate to the client but are not deletable from the client because
they are in the `$:/temp` namespace.
cc @loleg
The previous fix changed the scrolling behaviour such that it only
scrolled to the top of a tiddler if the tiddler was entirely offscreen.
It wasn’t entirely satisfactory because scrolling was prevented even if
only a few pixels of a tiddler are in view. This commit ensures that
the scroll does occur if less than 50 pixels of the target is in view
tv-get-export-path tells render tiddlers where to export files
tv-get-export-image-link tells images.js where to look for images
tv-get-export-link tells tells link.js where to look for links to other
exported tiddlers
@aelocson here’s an alternative fix for #981, as discussed in
https://github.com/Jermolene/TiddlyWiki5/commit/691e5719a4ff74a04d389bd1
26ba2a69e7651a2a#commitcomment-9848682
It does seem a lot nicer. It avoids the problem you raised, and also
avoids scrolling when a permalink is used.
I suspect that we’d need to make the hard-coded 50 pixels be
configurable.
This reverts commit b2b8006b58, reversing
changes made to e7e16137b2.
@welford my apologies it turns out there are a couple of problems, I’ll
comment more on the pull request
Previous changes since 5.1.7 broke the documented semantics by no
longer returning true when the versions match. It affected the upgrade
process, making it impossible to upgrade to a later pre-release (ie
where the version numbers in the upgrade.html match those in the file
being upgraded).
Also reviewed and updated the calls to checkVersions.
@felixhayashi I think that this effectively reverts the change you
original submitted. Are you OK with it?
Fixes#1415
The problem was that encodeURI() doesn’t encode slashes, which are not
legal in a data URI, although only Safari was failing. We switch to
encodeURIComponent(), which does encode slashes
The main fix is removing the fallback navigation to the first tiddler
in story.js. Also required is the fix to the startup behaviour of
zoomin.js.
Fixes#981
fixes#592
Introduces and preserves **_origin** field when using drag-and-drop —
bad idea? discard? different field name?
demo http://592.tiddlyspot.com
Fixes#1450
Provides support for an integrated plugin library that can be used to
install plugins from tiddlywiki.com directly to wikis hosted online or
offline. See the Plugins tab of Control Panel.
Todo:
* Error checking(eg libraryserver.js HTTP GET)
* Translatability
* Documentation
** $:/tags/ServerConnection
** savelibrarytiddlers command
for now, computes path to backup directory, appending the relative path
of UploadBackupDir to the absolute one from the UploadURL
Also added example for store.php to hint
Preserves compatibility with existing invokeActions call in button widget by creating a separate 'invokeActionCall' function to carry out the recursion. Triggering all descendants permits use of action widgets inside list widgets or macros. Also makes it possible to add triggering capability to select widget.
when the tiddlers are not listed in the list field, sort them by title
nonetheless, otherwise we get a real poor taglist from
**$:/core/ui/TagTemplate**
Ok, I think I've got it now. The following matches all...
1. starting with a literal `$:`
2. then any number of character not a whitespace, `<` or `|`
3. closing with anything that is, again, not a whitespace, `<` or `|`
Test here...
http://tbdemo.tiddlyspot.com/#Autolink%20System%20Tiddlers
enhanced extlink parser to cover system tiddler links
of course, only those without spaces in their title
didn't want to open up an extra parser for this as extlink has all the
basics
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.
With this commit tag pills will now choose for the foreground colour
either the current palette “foreground” or “background” colours,
according to which has the higher contrast. It’s something @gernert has
expressed an interest in in the past, and I’ve tended to agree that it
is a nice piece of polish. It opens up the possibility of paler colours
for tag pills than are currently possible.
The trouble is that in order to implement it I’ve had to bring in a
third party library for parsing CSS colours. It weighs in just over
9KB, making quite a lot of weight for such a small feature. I don’t see
any other immediate uses for the colour parsing library either.
So, I’m undecided at the moment whether this should stay in the core.
Dragging a tiddler link into a tiddler editor, or outside the browser
into another app, will now add double square brackets around the title
if it includes spaces. Suggested by @tgirod.
I’m not 100% sure about this change. It breaks one habit that I had
developed: typing `[[sometext|]]` and then dragging a title in between
the vertical bar and the first closing square bracket. What do others
think?
Also added a “description” field for wiki folders.
Right now there’s too many editions listed. I think we should by
default only list editions whose `tiddlywiki.info` file has
`showInListings` set to `true`, and have an `--editions all` command
that lists everything.
@pmario please could you check that the editions in your
`TIDDLYWIKI_EDITION_PATH` are correctly listed?
Resolves some inconsistencies over the behaviour of the new tiddler
message under various circumstances.
“new journal here” when a journal for today already exists now brings
up the existing journal for editing, and adds the required tag.
I’d be very grateful for any testing of the behaviour here: try using
new tiddler, clone tiddler, new here, new journal here, and new journal
in various combinations (eg with the draft not existing, already
existing, open or closed etc), and let me know of any peculiarities.
There are still some warnings about making functions in a loop, but
I’ll fix those as a separate pull request because the fixes are more
than typographic errors.
Re-introduces the “tw-auto-save-wiki” message. The previous approach of
automatically triggering autosave whenever a tiddler changed meant that
changing configuration changes in control panel was triggering an
autosave. Using the explicit message gives us better control of the
situations in which we’ll autosave.
Now we solve the earlier problem of there being outstanding tiddler
change events at the time that we process the “tw-auto-save-wiki” by
deferring the autosave until the outstanding change event comes in.
Mistakenly, I had changed the tiddler widget to refresh itself when the
value of the target tiddler changed. This is not in fact necessary; it
only needs to refresh itself when the identity of the target tiddler
changes.
Fixes#744
Previously we were using a message `tw-auto-save-wiki` to trigger an
autosave. The message was generated by certain UI actions such as
saving a tiddler. The trouble was that the message was being processed
before the wiki change event for the accompanying change had had a
chance to percolate. The end result was that the dirty indicator was
staying lit when using autosave.
The new approach abandons the autosave message and instead triggers the
autosave in the wiki change event when a relevant change occurs.
One happy side effect of these changes is that the dirty indicator now
works as expected with the client server edition - ie, when typing in a
draft tiddler the dirty indicator will flash briefly, and then clear
when the sync mechanism has completed saving the draft.
Fixing problems caused by c4b76ceb0b:
* We still need to initialise the saver-handler even when syncing to a
server, otherwise offline snapshots can’t be saved
* We need to override the default save template a bit further up the
stack, to avoid the server side serving the offline version of the wiki
at `/`
Fixes#717
The issue was that under Windows we generate text nodes that contained
CRLF as a linebreak (rather than just LF as usual).
The subtle problem is that when these strings are placed in the DOM via
createTextNode(), the CR character is treated as a printable character,
not whitespace. When creating DOM notes with innerHTML or as part of a
static HTML document the HTML parser will strip out the CR characters.
The hacky solution is to manually remove CRs before building the text
node.
