* 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.
* 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 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
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.
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".
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.