[Feature request] Review hierarchy

[cashpw]

Allow the state of a card to block other cards from appearing in the review queue.

As an example, consider two cards: (1) where the capital of Italy is on a map and (2) which city houses the Colosseum. And say you want to wait to study things in Rome until you can place it on a map. It would be nice to be able to define a relationship between the two cards such that card 2 isn't added to the review queue until the positions in card 1 are above a specific box (e.g. 2).

[l3kn]

This sounds tricky to implement.

There would need to be some kind of optional "blocked" property on a card,
ideally an ID + position pair.

The hard part will be to reliably and efficiently get the review data (box) of the blocking card,
and to get a list of all cards / positions when first setting a blocking card on some card.

org-fc-cache solves parts of that problem, but it's an optional feature.

[cashpw]

org-fc-cache would be a huge help -- maybe enough to require it be enabled if the user wants to have any blocking cards.

[cashpw]

To expand here a bit: I had originally thought of this feature in the context of incremental reading. I imagined a few features coming together:

1. An optional feature for priority-ranking cards
2. Cards can block other cards

I would create a priority-rank-enabled "deck" (see #87) wherein (perhaps in a custom function if it's not appropriate for the repo as a whole) reviewing a card increments the priority of that card. The priority ranking is used to return to the article/book/etc soon after I've completed the associated blocking reviews. As an example:

1. I start a reading review session and read one card. I create a few blocking cards. The reading card now has a priority of 1.
2. I start another reading review session and read two cards. I create a few blocking cards. These reading cards also have a priority of 1.
3. I start a general review session and get through all the blocking cards.
4. I start a reading review session and am presented with the now unblocked cards before any others in the "deck".

[l3kn]

Let me take this in a different direction, focused only on incremental reading.

As an alternative to blocking one card by another,
cards could be blocked by all cards appearing before them in the current file / heading.
This way, there is no need to manually set blocking cards.

org-fc supports nested flashcards, so a structure like this is possible:

• Chapter 1 :fc:
  Short summary
  • Card 1 :fc:
  • Subtopic
    • Card 2 :fc:
    • Card 3 :fc:
• Chapter 2 :fc:

Assume introducing new knowledge (e.g. creating new cards from sections of a book) into this structure is a separate task.

The current review process is built around the the ability to efficiently review large amounts of cards separated over many files
(for context, I'm using org-fc with ~20k cards split over ~3k files).
This scale is at odds with any kind of advanced scheduling or blocking logic.

If we limit our scope to reviews of single files, another approach becomes possible:
instead of reviewing a list of cards that was computed beforehand,
at each step of the review, we select the next best card from the buffer we're visiting.

To select a card, we move through the headings and search for a new card.
Once there are no more new cards, we search for the next due card.

Under my proposed parent-blocking strategy, if we encounter a card that's blocking
(either due for review, or still in the learning phase), we skip the subtree below it (or the rest of the file).

Note that the card selection process already accounts for the case where a card is blocked by a parent card being due,
as that parent would have been visited earlier in the review process.

With your strategy of blocking one card by the ID of another,
we can do the same search through the headings (including all subtrees, in case parent-blocking is not active)
and if we find a card that's due but has a blocker attribute, we check the blocking card in the context of the current file
which should be sufficiently fast.