Currently prop searches and the retrievability column will continue to
derive the days from the card only, as it's difficulty to integrate revlog
upgrade lookups into those code paths, especially in a performant way.
One possible way we could solve this in the future is to store last_review_day
in the card data, so we can know it even if the due date has been shifted.
Check DB could fill it in for existing cards.
* Draft set optimal/calculated retention button
Temporarily save the calculated optimal retention and display it with a button
that sets the desired retention above to this value.Don't show button until
attention had been calculated. Disable button when optimal and desired
attention are equal.
I find this nicer than the current alert-popup solution, as it avoids a popup
and gives a choice to the user to accept the calculated retention or not, while
also persisting the calculated retention on the screen for a bit.
TODO: What's still missing is that the `optimalRetention` variable is global and
persists when I change presets. When changing presets the variable should reset to
`undefined`, which would also makes the button disappear. Ideally it should also
disappear when changing the FSRS parameters. So probably it should be made part
of some deck options state and subscribe to some events. But with that I might
need some help. Also I thought whether that variable should go into the deck
options schema but tbh it's not something we want to persist between sessions,
users should recalculate it.
* Add me to contributors for tests so pass
* Add formatting ant type fixes to make tests pass
* Minor fixes (dae)
* Remove the period
It's very helpful having a sub-permille precision in a progress
indicator, percent-precision or at most a tenth of a percent should be
sufficient for any indicator.
But in particular the compute-retention progress has 10 steps, i.e. the progress
increases in 10%-intervals (10%, 20%, ...), it *cannot* have sub-decimal
progress-percentages, see 2d5b19b494/src/optimal_retention.rs (L365-L368). So there integer percents should be
enough, everything else is misleading.
The compute-weights progress is currently (as of beta-2) not showing up at all.
Maybe if the bug is fixed it can show sub-percent percentages, so for know I changed that
to 0.1% precision. But I think integer percentages should be fine here as well,
so upon request I can fix that.
Also see my comment on this problem in https://forums.ankiweb.net/t/anki-23-10-beta/34912/39.
If we want to be able to factor the desired retention into a sort based
on relative overdueness, having the values accessible on the card makes
things easier.
Allowing some decks to be FSRS and some SM-2 will lead to confusing
behavior when sorting on SM-2 or FSRS-specific fields, or when moving
cards between decks.
