* Add suffix and parameter to trim operator
Fixes#4809
* Unit tests for new trim operator parameters
* Mention trim operator in 5.1.23 release notes
* Address review comments
* Move regex escaping into utils.js trim functions
This way the trimPrefix and trimSuffix functions from utils.js are safe
to call without regex-escaping their parameters, which should make them
easier to use from other parts of the Javascript code.
Most astral-plane text is emojis like U+1F4DA BOOKS (📚), but some
languages like Osage have their alphabet entirely in the supplementary
multilingual plane as well. For proper support of languages like Osage,
and newer emojis, the UTF-8 decode and encode functions need to properly
handle codepoints above U+FFFF, which are represented by a surrogate
pair in Javascript strings.
* The `!has[tags]` filter didn't work because "tags" is an array
The negated `has` filter only considered empty strings, but not empty
arrays (such as the `tags` field).
* Add tests for `has` filter operator with array-like fields (tags, list)
* Add tests for backlinks
* Add backlinks indexer
* Use backlinks indexer in getTiddlerBacklinks if available
* Extract link extraction into its own method
This way we can provide an arbitrary parse tree, rather than just a
title, which will allow us to compare lists of outgoing links between
versions of a single tiddler
* Use new extractLinks method in backlinks indexer
...rather than copy-pasting the implementation
* Remove ES6-isms
TiddlyWiki needs to work with browsers that only support ES5
* Fixes issue with #4504 and importvariable copying
ImportVariables widget was using $tw.utils.extend to copy the
variables from temporary set widgets into itself. However,
$tw.utils.extend does NOT behave like Object.assign. It not only
copies all self-owned variables over, but also all variables
in that object's prototype chain. This led to some redundant copying,
and a problem where some variables might show up more than once
(like transclusion).
Fixed now. importvariables widget does its own copying, since it
can't rely on $tw.utils.extend to do the right job, and it can't
count on Object.assign to be there.
* Added test to prevent reversion of #4504
* Slight corrections to new importvariables test
* add a new-line before the log text to increase readability of the test output
* make eslint, jslint happy
* make eslint happy
* add more listops tests
* new listops filter tests
* remove new-line
* make eslint happier.
* revert eslint settings
* Changed importVariable to store its ownvariables
Before, importVariables was creating a setWidget for every single variable it would find in its tiddlers, and it would create a long-ass call tree. Now, instead, it just accumulates the variables in itself.
* Can't use Object.assign
Learned the hardway while working on tw5-relink that Object.assign
doesn't exist in IE11. Using $tw.utils.extend instead.
* Retaining setWidget transclusion flexibility
* One more test to verify mixing sets and macros
add 3 new tiddlers, add 1 "enlist" test, fix all tests that failed, because 3 new tiddlers where added. stopped ESLint to complain about global vars, fix some mixed-tab-space indent typos.
* process.exit() only exist in a node.js environment
* updateInterval has been removed from upstream
From upstream commit:
b6eb9a4d5e
* Update Jasmine to 3.4.0
* Reuse the evalInContext helper
* Fix expected parse result to match the actual result
* 'describe' cannot be nested inside 'it' blocks
Jasmine started to explicitly raise an error in these cases since:
https://github.com/jasmine/jasmine/pull/1411
* Be consistent about how to refer to library files
* Update link to Jasmine's official website
I (Flibbles) changed it so that lists generated by stringifyList
would always be compatible with a filter parser, but since lists
are not, and never will be, a subset of filters, there isn't a
point.
More importantly, wrapping negative numbers like "-7" in brackets
would mess up some math stuff.
Fixes#4082
This version removes selective updating of the tag index, instead completely clearing the index on each update. I'm investigating restoring that optimisation.
The test rig previously used a simplified implementation of shadow tiddlers which broke with the new indexing engine. There was also a problem that made that even if indexers were disabled they were still initialised.
This PR fixes both problems, in preparation for fixing #4082
* First pass at modular wiki indexes
An exploratory experiment
* Fix tests
* Faster checking for existence of index methods
We don't really need to check the type
* Use the index for the has operator
* Fix typo
* Move iterator index methods into indexer modules
Now boot.js doesn't know the core indexers
* Fix up the other iterator index functions
* Fix crash with missing index branch
* Limit the field indexer to values less than 128 characters
* Fallback to the old manual scan if the index method returns null
* Sadly, we can no longe re-use the field indexer to accelerate the `has` operator, because the index now omits tiddlers that have field values longer than the limit
Still need to make the index configuration exposed somehow
* Rearrange tests so that we can test with and without indexers
We also need to expose the list of enabled indexers as a config option
* Test the field indexer with different length fields
So that we test the indexed and non-indexed codepaths
There are other ways we could add maths to TW5 (including @EvanBalster's awesome https://github.com/EvanBalster/TiddlyWikiFormula) but the approach here has the merit of simplicity because it reuses the existing filter evaluation mechanism. That means that it's not ordinary "2+2" maths, it's a unique list processing language...
Docs to come
Fixes#254
* Fix search method for search tokens spread across fields
Addresses GH #3636, which reports that if you're searching for "test
body", and "test" only appears in the title field, and "body" only appears
in the text field, 5.1.18's search method won't yield that tiddler as a
result, which appears to be a regression from the 5.1.17 behavior
* Add test for searching for multiple tokens across fields
Verifies GH #3636:
> If I create a tiddler in the empty edition with the title "Test tiddler" and content "Body content", searching the wiki for "test body" yields no results under either "title matches" or "all matches". Searching for either word individually turns up "Test tiddler", and repeating this in an empty wiki I created from the 5.1.17 tag causes "Test tiddler" to show up under "all matches".
* Added better handling for sortByList manual placements
If manual placement specifications show up in an inconvenient order,
sortByList, will go to the trouble of processing them in that order.
* Added tests to confirm solution to (#3296)
...That custom tag ordering will not choke when tiddlers get sorted after their dependencies have been placed around them
* Corrected list-after bug when referencing external titles
* Using more error-proof $tw.utils.hop in sortByList
* minor indentation correction in test-tags.js
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.
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?
Fixes#82.
The old behaviour was to parse the content of a widget or html element
in block mode if the opening tag was followed by a line break. The new
behaviour requires two line breaks.
This makes it possible to include linebreaks more liberally within
wikitext, although care must still be taken to only use double line
breaks when the block mode behaviour is desired.
The code change here is very simple, just a single line change in
html.js. Most of the other changes are to convert various single line
breaks into double line breaks.
In some timezones, (eg GMT+6) the modified timestamps for the
'TiddlerOne' and 'Tiddler Three' test tiddlers were actually on
the same day. This was causing the 'eachday' filter test to fail.
Similar to the fix in commit 8487221, this just adjusts the
timestamp to ensure the test passes in any timezone.
In certain timezones, 201304151312 UTC is not actually the same day
as 201304152219 any 201304151756. This was causing the test for the
'sameday' filter operator to fail. (I'm in GMT+10).
This is a quick-fix. I've just adjusted the timestamps to be close
together so they will be same day no matter what timezone you're in.
