Support for cloze deletions

[r0uv3n]

Thank you for this great Add-On!

Cloze deletions can be a great tool for learning mathematics (and other sciences), compare for example with this blog post. A way to include cloze deletions via a command in LaTeX (which would then be automatically converted to a cloze deletion when importing) would be great. A possible syntax could be \cloze{cloze number}{cloze text} (getting converted to {{c(cloze number)::(cloze text)}}, where parentheses just indicate variables. I believe supporting automatic numbering (so that the cloze number could be optional) would probably not be trivial, but could still be a nice comfort feature if one wanted to implement it. It seems Anki itself just uses (highest processed cloze number so far)+1 for new cloze deletions added in the editor.

[TentativeConvert]

Good idea! Can't make any promises, but if I do find some time to work on this addon, this will be top of the list.

[TentativeConvert]

With the current version, what happens if you just use Anki's syntax ({{c(close number)::(cloze text)}}) in the tex file? I understand that the cloze won't be nicely formated when compiling the tex file outside of Anki, but I guess it does nevertheless compile. Does anything go wrong in the conversion upon importing to Anki, or do you end up with a working cloze in Anki?

[TentativeConvert]

Having thought about this a bit, I slowly remember that there were several reasons why I decided against support for cloze deletion before.

• It would be very difficult to implement it in the current code. Correctly identifying matching braces in a command of the form \cloze{…tex-code…} would require little less than a full-fledged tex-parser. The tex-code could go over several lines, and coud include comments that include curly braces … I believe there are python packages that can parse tex code, and I should probably have used one of those in the first place, but it's too late now. Only a complete rewrite could implement this robustly.

• You can simulate cloze-cards with normal cards. This takes a bit of editing, but once you're creating your cards in a text editor, copy-and-pasting (slight variations of) fields is easy.

• If you simulate a cloze-card with a normal card, you have much more control over the final layout in Anki. With native cloze support, the layout of a card will typically depend on the whether the cloze text is hidden or displayed. Eg:

   A … with a cloze at the beginning.

  might acquire a line break when the hidden word is display:

   A sentence with a cloze at the
   beginning.

  If you simulate the cloze-card with a normal card, you can keep the layout fixed (e.g. by the hiding text simply with white text-color.)

• If you simulate a cloze-card with a normal card, you can display an inline-hint instead of the cloze text.

I made extensive use of "simulated clozes" in the following deck: https://www.overleaf.com/read/jrdcnnkfvwrq

(As a final comment, in case you are still thinking about implementing support for a \cloze command yourself, it would not be universally useful to number clozes automatically upon import. Think about a scenario where you edit a tex-file that you've already imported into Anki. What if your edits include moving clozes around? How would you want the clozes to be numbered when you re-import the file into Anki and update existing cards? If you want matching clozes to get updated correctly, you'll need to number them explicitly.)

So this is a no-fix. Of course, it would be useful to describe how to "simulated clozes" in the documentation.

[r0uv3n]

Thank you, this is very understandable. I'll stick with the "simulated clozes".