* Add icon for view template segment
* Muted background colour for view template segment
* Include links to parent tiddlers in the view template segment
* Fix logic for hiding/showing documents/headings (“open”/“close” were
transposed)
Without modified dates, new imports do not appear in recent file list. The equivalent of modified dates in ENEX is the 'updated' tag, with a date format similar to that of TW with the exception that the date format consists of a date stamp, a letter T, and a time stamp followed by Z for UTC presumably. There is no millisecond indicator. Not all ENEX notes have an update tag. The solution here is to apply creation date by default and then apply the update date if it is available. Dates are converted by stripping out Z and T and appending '000'.
@sukima the main issue with the previous code was that it incorrectly
used comma to delimit tags. We actually use spaces, and double square
brackets to delimit tags containing spaces. Better is to leave the tags
field as an array; the core will serialise it correctly as required.
I also made some minor consistency tweaks.
Relates to Issue #2268
I tried to map over the list of tags but NodeLists are not arrays and so
need to be converted. This looks ugly and probably should be abstracted
to a function. Come to think of it should we have a `$tw.utils.map()`
function?
Relates to Issue #2268
Based in the [example XML][1] attachments are listed in the <resources>
node. Since in TiddlyWiki these would be media tiddlers I add then one
by one as separate tiddlers.
There are some things that still need to happen. There should be a mime
type check so we don't attempt to import media tha TiddlyWiki doesn't
support. Also the example suggests the data is base64 encoded so I
blindly use that for the text attribute. Should there be a
`data:mediatyp;base64,…` prefix?
[1]: https://gist.github.com/evernotegists/6116886
Integrating this module allows us to do HTML/XML parsing under Node.js
(there is no built-in support for Node.js; we can already do HTML/XML
parsing in the browser). The implementation chosen is pure JavaScript,
and will work in all configurations of TiddlyWiki.
The immediate motivation is the work I’m doing to integrate with Amazon
Web Services.
We should be able to use JSZip to export multiple tiddlers in a single
operation from the browser.
Instead of showing a sequence of all documents in the preview column,
we just show a single document, with a dropdown to choose which one is
shown.
The change makes it easier to deal with large numbers of documents.
The metadata for each field is in a tiddler tagged
`$:/tags/DocumentMetaData` with the field `caption` being the displayed
caption for the field and `field` being the name of the field.
`field-type` is the type of the field, and can be “string” or “list”.
Previously, newly created image files would end up being saved as a
base64-encoded .tid file. Now they are saved as an ordinary binary file
with an accompanying .meta file for the metadata.
By making the docs available as a plugin we make it easier for people
to fork their own copy of the docs without losing the ability to get
updates in the future (which can be done just be updating the docs
plugin)
Many reasons:
* to allow subtrees to be grafted more easily
* to keep the tags for an entry clean by removing structural tags and
leaving the semantic tags
* to avoid the duplication of expressing the same relationship through
both the tags and list fields
1. Switch from using the text field of lists for storing the associated
filter to using the field `toc-list-filter` (to make it harder to
accidentally parse the text of an ordinary tiddler as a filter)
2. Fix several bugs
The exclude filter `+[tag[intro]]` will produce a document that only
includes the paragraphs with the tag “intro”. These are derived from
the paragraphs in the original document with the CSS class “intro”.
* Add warning in document tiddler toolbar if tiddler already exists
* Live preview document in new window
* Fix slicer.js bug that was preventing the list field of headings from
being filled in correctly
* Rationalise some class names
Now includes a special document view column on the left. Headings can
be expanded/collapsed, and tiddler titles can be inspected and renamed
via the toolbar. Clicking on an entry opens the associated tiddler. The
default tiddler view template includes a special section for tiddlers
that are part of a document
Now we process the rendered HTML of tiddlers, which allows us to
process HTML generated by MS Word. In fact, the HTML that MS Word
generates is so awful, I’ve instead been using Mammoth to do the
conversion: https://github.com/mwilliamson/mammoth.js
Also some necessary improvements to the fake dom implementation.
1. Introduce template tiddlers for the document, each tiddler, and the
tiddler toolbar
2. Move the text slicer toolbar button to the left of the edit button
3. Add a selectable toolbar, currently just containing the tiddler title
We’d rather present this information as a panel within the tiddler
editor so that we can (for example), allow clicks on a snippet to
insert it automatically into the editor at the current cursor position.
For the moment, we’ll just remove the cheatsheet. Post-5.1.8 we’ll add
it back to the editor
* 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>`
There was a rendering mess in the CodeMirror readme file. This was cause
by attempting to bold the `$:/tags/Stylesheet` text. Also the context of
the sentence implies this should be backticked not bold (it refers to a
tag not a tiddler).
This is just an idea really.
The help plugin is only included in the tw5.com wiki; the idea is to
also include it in the empty.html wiki, either as a plugin or as part
of the core.
If it stays as a plugin, the idea would be to have different help
plugins for different languages.
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
split the latter half of highlight.pack.js into a separate file which
registers all the languages and exports hljs. this is for nodejs
compatibility and mimics the way the highlightjs module works in nodejs.
Without sorting the list, we had ordinary tiddlers listed before shadow
tiddlers. That meant that as soon as you started to type in a shadow
tiddler it moved up in the list.
* Added support for translating the core readme
* Fixed problem with `Misc.multids` rendering shadow tiddlers
* Fixed problem with single tiddler files rendering shadow tiddlers
The user interface needs some refinements but it shows the basic
principles.
The idea is that the translator would email their modified file, which
would then be merged into the core repo (some additional tools will be
helpful for this).
Fixes#984
This code was contributed by @natecain and added in #176. It was almost
immediately disabled because of problems in the field.
I’m removing the code now to simplify the adaptor in advance of some
planned refactoring.
Fixes#855 - albeit it’s a bit of a kluge. The internal format returned
by `markdown.toHTMLTree()` isn’t sufficiently well documented for me to
be confident that the new code is resilient to all the things that
might be returned.
The control panel isn’t the right place for tools; it’s a place for
settings and internal configuration.
Once again apologies to the translators for wiping out your hard work!
