Add org-fc-max-positions-per-review

[dalz]

Reviewing e.g. the front of a flashcard after the back makes it artificially easier, and I'd like to avoid that. The commit introduces a variable that allows setting the maximum times the same card will appear in a review session. It may be worth shuffling due before taking the subseq, but I guess it depends on how the cards are set up and I'm setting org-fc-max-positions-per-review to 1, so I have no experience to say what would be best.

[l3kn]

That's an interesting feature!

Can you think of a scenario where setting org-fc-max-positions-per-review to a value other than 0 or 1 would be useful? Maybe a boolean value would be enough.

In Anki this is called burying of sibling cards and it doesn't affect cards in the learnig phase (the first 1 or 2 reviews in org-fc).

Reviewing e.g. the front of a flashcard after the back makes it artificially easier

I've logged 155k reviews so far, I'll try to group them by review session and compare the review performances of the first & following positions.

Another aspect is that there are some card types (cloze enumeration, cloze single) that shouldn't be affected by this, I'm not sure how to handle that though.

[dalz]

Can you think of a scenario where setting org-fc-max-positions-per-review to a value other than 0 or 1 would be useful?

I was thinking that the more you see a card during the review, the easier it becomes answering it; however if you have cards with many positions seeing just one could slow down the review too much, or maybe you could be comfortable with repeating the card a couple of times but not more. As I said I'd set it to 1, so if you believe a bool would be better I won't argue with that.

Another aspect is that there are some card types (cloze enumeration, cloze single) that shouldn't be affected by this

Indeed they should be excluded, I'll see what I can do about that.

[l3kn]

Because of the random "fuzz" added to card intervals, the probability of two positions of a card appearing in the same review session decreases over time so the review should not be slowed down too much using a boolean "bury siblings" value.

A lot of my cards have two positions, if I changed the positions per review to >= 2 to account for a few large cloze deletions, all of these double cards would be reviewed in a suboptimal way.

We could come up with special rules for all of this but I don't think it's worth the added complexity.

I'm not sure what the best way of excluding enumerations & single cards would be, since it should be possible to define special behaviour like this for user-defined cards, too.

I've experimented with using the Emacs object system (eieio) for cards, a lot of problems like this could be solved by providing a default implementation that's inherited and then adding custom implementations per card type when necessary.

I think "boolean" burying of siblings would be a good first step, we can figure out the details later.

[dalz]

The configuration variable is now org-fc-bury-siblings, which is boolean. It may be confusing if someone is coming from Anki, since as far as I can tell burying in anki means the card won't show up until the following day, while as of now it will be presented in the next review. Cloze enumeration and cloze single cards are ignored, however this can't be customized. To do the filtering I added :cloze-type to the card plist.

[l3kn]

Nice! I don't think the difference in behavior from Anki is a problem.

org-fc-type-cloze-type-property is customizable and needs to be included in the org-fc-awk--indexer-variables.

I think it was a mistake on my part to handle cloze card subtypes with a new property, maybe I can fix it when I figure out the class-based card implementation.

[dalz]

~For some reason git push hangs, I'll push the change after I find the issue.~ Should be good now.