when a card has a low interval like 1, you can end up with next times of
2,2,3, which some users think is a bug. change the code to yield 2,3,4
instead.
It has caused two issues in the last few days:
- A user thought their failed cards were mysteriously disappearing
- A few users with 1 day+ re-learning steps had thought they hit a bug. What happens is they fail a card on day 1 and its review interval is set to day 2; then a few days later after a few steps, they fail it again and it enters queue 1, but when the queue is rebuilt the steps are discarded because the original review repetition is due.
It might be possible to fix the above, but for 2.0 it seems like the safest bet is to remove this feature, especially as nobody actually asked for it and I just thought it might be handy.
- cram decks no longer pull cards from other cram decks, as tests like is:due
don't make sense on crammed decks
- cram decks now default to not overriding the original deck's steps
- remove obsolote dyn_failed sort order - have to fix this in upgrade
- search/limit/order properties have been merged into a list, in case we may
want to support multiple queries in the future (eg 10 cards from tag A, 20
cards from tag B)
- added a resched option to disable boosting/failure - not yet implemented
- added an unused flag to allow cards to persist in the cram deck after
graduation. implementing this will take some work and won't come in 2.0
- instead of is:filtereddeck, use deck:filtered
- new per-character tokenizer that is easier to read and maintain
- OR searches now supported
- grouping with ( and ) now supported
- sorting is off by default now
- searching in html is disabled for now, but may come back later
- use ? arguments instead of named arguments to ease porting to other
platforms
- field:foo is no longer wrapped in implicit wildcards
- avoid joining notes table if it not required - about 30% faster
- fixed sql injection bug in findNids()
- commands no longer have to take care of negation themselves
- commands can return nothing to immediately flag the query as invalid
The way we were handling 1 day+ learning intervals was not great - they'd show
up at the start of a new day before normal reviews, meaning the hardest cards
came first. In previous Anki versions we deliberately sorted the queue in the
opposite order to prevent that. When relearning the cards the next day, if you
failed a card and expected to see it in 10 minutes that wouldn't happen
either, as all the overdue cards took precedence.
To fix this, we put cards that are due tomorrow or later into a separate queue
(queue 3), and pull cards from that queue only after the reviews are done. In
the future it might also be nice to move overdue learning cards into that
queue automatically at the start of a session.
When a user has learning steps that extend past the daily cutoff, we end up
counting them all instead of only the ones that would be done today. In order
to avoid this without expensive calculations or db schema changes, we
calculate the number of steps until the daily cutoff and pack it into the left
column, as totalLeft + leftToday*1000.
- When we reset() the deck, we need to update the daily counts for all decks,
not just the selected ones, or the deck list is inaccurate
- We don't want to save the decks at that time, or simply opening Anki on
another machine will cause a conflict with all decks
