b3b40933c2
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. |
||
|---|---|---|
| .. | ||
| .cargo | ||
| build | ||
| cargo | ||
| src | ||
| templates | ||
| tests/support | ||
| .clang-format | ||
| .gitignore | ||
| backend.proto | ||
| BUILD.bazel | ||
| Cargo.toml | ||
| clang_format.bzl | ||
| proto_format.py | ||
| README.md | ||
| rustfmt.bzl | ||
Anki's Rust code.
backend.proto stores the interfaces used to communicate backend messages between Rust, Python and TypeScript.