The previous approach worked when the user pushes their due date back,
or moves it forward a little bit, but breaks down if they reschedule
shortly after the previous answer - a card that was only just answered
will have had an effective delay of 0, causing the interval to be
reset, which is not great.
I thought about limiting interval reductions, but that means the
behaviour is inconsistent when sending a card forward and moving it
back again.
We could apply a cap to the amount of interval we'll reduce, but that
will either doing something like dividing by 2 (which breaks down when
the action is performed repeatedly), or or looking up the review log
to try and determine the previous interval we should not go below.
One other option we might want to consider in the future is using
the revlog to calculate the actual elapsed time at answer time instead
of reschedule time, falling back to existing behaviour when the revlog
doesn't match or is missing.
- SearchTerm -> SearchNode
- Operator -> Joiner; share between messages
- build_search_string() supports specifying AND/OR as a convenience
- group_searches() makes it easier to negate
While implementing the overdue search, I realised it would be nice to
be able to construct a search string with OR and NOT searches without
having to construct each part individually with build_search_string().
Changes:
- Extends SearchTerm to support a text search, which will be parsed
by the backend. This allows us to do things like wrap text in a group
or NOT node.
- Because SearchTerm->Node conversion can now fail with a parsing error,
it's switched over to TryFrom
- Switch concatenate_searches and replace_search_term to use SearchTerms,
so that they too don't require separate string building steps.
- Remove the unused normalize_search()
- Remove negate_search, as this is now an operation on a Node, and
users can wrap their search in SearchTerm(negated=...)
- Remove the match_any and negate args from build_search_string
Having done all this work, I've just realised that perhaps the original
JSON idea was more feasible than I first thought - if we wrote it out
to a string and re-parsed it, we would be able to leverage the existing
checks that occur at parsing stage.
I was a bit too enthusiastic with using borrowed values in structs
earlier on in the Rust porting. In this case any performance gains are
dwarfed by the cost of querying the DB, and using owned values here
simplifies the code, and will make it easier to parse a fragment in
the From<SearchTerm> impl.
- draw a border between sidebar and main area
- tweak padding
Testing is a pain, because you need to check day mode on the
three platforms, and night mode as well. If you can do it better, PRs
are welcome :-)
This frees up Ctrl/Shift+left click to behave like in a typical GUI
app. On a Mac users can either two finger click, or Command+click in
conjunction with one of the other modifiers.
https://github.com/ankitects/anki/issues/1011
I thought this could work, but users (including myself!) are used to
being able to shift+click to select a region, and this behaviour is
surprising. We're also doing potentially expensive searches for each
extra selected item. I think we may need to switch this behaviour to
the right mouse button instead.
This partially reverts commit c91d21e18e.
1. Clicking away from the editor window, and back on it should not focus old field
2. Clicking on a field, which is not fully visible, should scroll it into view
'Current deck' has moved, and by removing 'due tomorrow', we can drop
the 'today' suffix on the rest of the items.
The keys of the existing translations have not been changed, so
existing translations will not break, but will need to be manually
updated to make them shorter.
This is to provide minimal closures for the mutable file-local variables:
- changeTimer
- previousActiveElement
- currentNoteId
This makes it clear, that they should not be used, but rather the
functions which wrap them in an API
