Reordering cloze-holes and “invisible anki”

[l3kn]

This is a really nice generalization of cloze deletion!

If I were to rewrite a paragraph marked as a flashcard in a way that changes the number or order of the deletions, would that mess up the spacing parameters used by Anki?

At the end of the readme you mention an “invisible anki” experiment which sounds very interesting. I can imagine how parsing paragraphs and lists in a file would allow splitting it into cards, do you have more information on this?

[meedstrom]

Congrats for spotting that possible problem! I'll quote myself in the user manual: https://github.com/meedstrom/inline-anki/blob/master/doc/inline-anki.org#to-push-cards

There’s a bit of a gimmick: if a note has 3 clozes, and you study it a bit, and later you remove the first cloze, the second and third cloze cards will inherit the scheduling of the first and second. So technically, you can have cards that aren’t scheduled in full faithfulness to the algorithm, and failure statistics may be referring to a cloze card that you’ve removed.

I personally am not bothered by this, but if you are, I suspect there's no way around having to manually number the cloze-holes. How would you like that to look? Where in each cloze-hole should the number go?

For invisible-anki, I was simply thinking of doing a text comparison. So a 75%+ match or so would be taken to be the same flashcard. It's pretty inaccurate, so if too much changes between two versions, that's just taken as a new flashcard. I think it could be acceptable.

But for some kinds of data, like vocabulary, the front or back of a flashcard could work as an unique ID if it's expected to never change. This guy does it for vocabulary: https://old.reddit.com/r/emacs/comments/17dhila/new_package_to_scratch_an_itch_let_me_embed/k5z7ogt/

Anyway, if and when I roll it out, you'd still be able to use your inline-anki flashcards and just remove the numbers -- nothing else should need to change.

[l3kn]

Oh, I missed the documentation folder, thanks for pointing that out!

For some context, I've been building and using my own SRS for some years and in that time, I've noticed how the style of my cards has changed towards normal text with a bunch of holes marked in it, so what you're doing here is intriguing.

Text comparison might be tricky to implement but as long as either the order of holes changes, the text of a single hole changes or holes are removed/added, it should be possible to exactly determine the mapping between the holes before and after the edit. More complicated edits would then need to be broken up into series of smaller changes.

The only alternative that comes to mind (and the one I'm using currently) is to use a different set of hole-markers, each of which has a number in it. The downside of this is that the resulting cards looks less like normal text.

Maybe a hybrid approach is possible? The numbering is only relevant when editing cards, so it might be possible to have some command that temporarily (e.g. via text-overlays) adds the extra information needed to ensure a correct mapping when rewriting a card, and removes it after the card has been “saved” or synced with anki.

I hope you don't mind me using an issue for this kind of brainstorming, I couldn't find any other contact information in your profile.

[meedstrom]

No problem using an issue, that's what it's for :)

Yeah, text-overlays is how eli-qq gets rid of note IDs. A clever idea, but so fragile I wouldn't dare be responsible for people's flashcards like that.

Actually, your idea of temporary overlays leads me to an idea: what if we skip the overlays and just prompt the user for the needed info when we push to Anki? Like "new card has 3 fields, old had 4, which field should Anki remove?"

Unfortunately that doesn't react to reordering. So maybe overlays, but that only exist for the current Emacs session and don't persist across restarts. Maybe that's good enough. Though once again, overlays still aren't needed -- could just input the ordering-data as actual text :)

I suppose I could just let the order-numbers be permanent, and just make an emacs mode for visually hiding them as well as the note IDs.

[l3kn]

Prompting users for the mapping in case it can not be derived automatically seems like a good solution.

Looks like there's a spectrum with two extremes:

• attaching (and possibly visually hiding) IDs to everything, which is easy for a computer to process
• having fields (and possibly also cards) without IDs, which is easy for human users to write and read

Thanks for your input! I'm curious to see where you'll take this.