This commit corrects the following bug:
* Create a note N in an empty deck D of type basic (reverse), with
only some back, no front. Only card 2 will be generated.
* Edit the note, add a front. Card 1 will be generated.
* In the main window, try to learn deck D. In anki, currently, you'll
see Card 2 first. According to the manual (and to my common sens),
it should be Card 1 first.
This commit correct this bug, and ensure that new cards are seen
according to their order, and not to their creation date.
- move checking code out of the schedulers and into the deck manager
- ensure we can fix the problem in one loop - the previous recursive
approach could lead to stack overflows if the top level of a large
deck tree was missing. this was also the cause of the sqlite
'interrupted' error that some users were seeing
- fetch reviews from all child decks at once, sorted by due order
- shuffle the gathered cards as we did previously
- review limits on child decks are ignored - only the current deck and
its parents control what the limit is
- to make the deck list consistent with actual counts, we can't sum the
child counts, as the sum in the parent limit>child limit case may not
reflect the actual number of cards that would be presented
the previous approach meant we weren't able to preserve the card state
exactly when cards were in learning, since we didn't record the step
position prior to cards being moved into the filtered deck.
it also meant the answer buttons needed to change depending on state - 4
for cards in learning/review, but 2 when the card is on the final step
or is a review.
instead, in preview mode cards always have 2 buttons: again will repeat
again after a delay, and good immediately removes the card and restores
it to its previous state.
to accomplish this, we use a separate queue #, as the learn count
always needs to have a 1:1 correspondence to the number of cards
- move fuzzing into _constrainedIvl() so it's applied prior to limits
like maxIvl
- don't fuzz early reviews, so cards get the same interval if a filtered
deck is rebuilt again
fixes the following:
- create a filtered deck and sync it
- review cards in the filtered deck and delete it
- sync again
The filtered deck deletion was bumping the mod time on cards at the
start of the sync, preventing the reviews from being synced from the
other side, leading to lost reviews and sanity check errors.
commit 79ed57a445 prevented reschedule
on cards in a filtered deck, but it is more user friendly to
automatically move back to the home deck instead. we also don't need
to removeLrn() for review cards, because we're updating type+queue+odue
ourselves
if not, removeLrn() resets due=odue and odue=0, leading to an invalid
delay calculation when they're later reviewed in the filtered deck
to fix this we'll need to make the same changes required to support
learning cards retaining their state when being emptied from a
filtered deck
in the upcoming daily unburying, this could lead to a state
where the remote end unburies just at the start of sync
and clobbers more recent changes made on the local end
