* Weight search results by most recently updated
As discussed here: https://github.com/laurent22/joplin/pull/3777#issuecomment-696491859
Before this commit, results were rarely sorted by date. Content weights and fuzziness were
determined, and then the first criteria to differ would win in sort order (and user_updated_time
was the last criteria checked).
Now the weight score itself will also include age of user_updated_time, surfacing fresh content.
At the current alpha level, results are weighted logarithmically, prioritizing mostly within the
last 30 days, and especially heavily within the past week.
* Updated unit tests to weight search results by last updated date
* Updated unit test title
* Fixed issue with weighted search engine test, and made it more deterministic using mock date
Date was being calculated only at the start of the test suite. It also wasn't using a set mock date, so the milliseconds between the real search engine calculations and the test calculation caused differences in results
* Added initial Search Engine spec
* Added Search Engine spec to README.md
* Renamed Search Sorting spec per laurent22's mentioned naming
* Revised copy in search sorting spec
Co-authored-by: Laurent <laurent22@users.noreply.github.com>
Issue https://github.com/laurent22/joplin/issues/3711
This patch replaces the 'isLinux' check by a more restrictive version
which fixes the false positive in BSD systems. This was causing Joplin
not to load due to the lack of X11 in headless mode.
The implementation uses / symbol as a nesting separator. I.e. tag/subtag is a nested tag, where tag is the parent tag and subtag is its child. Creating a tag named tag/subtag/subsubtag creates three tags, one for each level. The tags are associated using parent_id field.
In the app, viewing notes with a tag will also show all notes that are associated with any of the tag's descendant tags (same for the note count). Deleting a tag will also delete all its descendant tags.
In the desktop app the tags are shown nested just like the notebooks.
The goal is to allow locking a sync target so that maintenance
operations, such as upgrading the target to a more efficient format,
can be done. For now, only the lock mechanism is in place, as a way to
evaluate it, and to see if it can cause any issue.