Un(der) documented feature: behavior of cloze replacement fields that do not contain instance cloze reference

[DRudel]

In my opinion there is a really nice undocumented feature relating to how cloze replacement markup is expanded when a cloze replacement field does not contain the cloze reference controlling a card.

In the Close Template section, I recommend a change to the general description of the business logic used to generate cards from cloze templates. The two main improvements I'd like to see are:

1. Emphasize that only cloze replacements on the front of the card are considered when determining what cards are created.
2. Indicate that a cloze replacement is ignored completely if it does not contain the controlling cloze reference, leading to extra flexibility when text is broken up across multiple fields. (I.e, the text in the field does not simply pass through as one would expect.)

A strawman is shown below.

- Anki identifies all fields that are marked as _cloze replacements_ (e.g. {{cloze::field_A}}) on the **front template**.
- Each such field is inspected for _cloze references_ (e.g. {{c1::XXX}} contains the cloze reference **c1**).
- For each distinct cloze reference, a separate card is produced.
- For the card corresponding to cloze reference Z, cloze replacement markup (e.g. {{cloze::field-A}}) is processed as described in the [cloze deletion section] **if** the field's text contains Z. If the field's text does not contain Z, the markup is ignored.

Example:
Consider the template

{{cloze::Field_A}}
{{cloze::Field_B}}

And a card with the following fields:
Field_A: {{c1::XXX}}
Field_B: {{c2::YYY}}

I believe a natural expectation of a reader of current manual is that "when making card X, and expanding a {{cloze::...}} element, markup of the type {{cX::AAA}} is occluded or replaced, and text inside other cloze markup act in a pass-through fashion: {{cY::BBB}} expands to BBB for Y != X.

So the template described above would be expected to present as the following for card_1:

[...]
YYY

When in reality the {{cloze::Field_B}} element would be ignored (i.e., expand to an empty string).

[DRudel]

I think it would be in keeping with the style of the pages involved if a technical, abstract version (like the one given in the OP) were included in the Cloze_Template section, and a more informal example provided in the Cloze_deletion section.

The latter could illustrate the intended flexibility and usage of this feature. For example, combining multiple sentences no the same card (for purposes of burying related information) but only showing a limited amount of text on each card.

For example:

{{cloze::field_A}}
{{cloze::field_B}}
{{cloze::field_C}}

Could allow the creation of 3-6 cards related to the same general information (which you may only want to see one of in a given session), but only the text relevant to a particular occluded item would show at once, reducing distraction.

[brishtibheja]

I knew of this, but I don't assume a lot of people have multiple fields for clozes so it seems like over-documenting here, unless we add a short sentence warning that multiple fields wouldn't work as expected.

[MNastri]

This feature halves the number of fields necessary to create several basic cards as siblings and needs only one card type to generate all the cards. I rarely use the basic note type anymore.

Example using a custom cloze note type (3 fields, 1 card type)

-Q1: What is the importance of the applied steps to query transformations?
{{c1::it adds a full audit trail of transformations}}
-Q2: what data can you see when you select an applied step?
{{c2::the data right after being transformed by the selected step}}
-Q3:as a good practice, should you rename the applied steps?
{{c3::no}}

Same example using a custom basic note type (6 fields, 3 card types)

-Q1:What is the importance of the applied steps to query transformations?
-A1:it adds a full audit trail of transformations
-Q2:what data can you see when you select an applied step?
-A2:the data right after being transformed by the selected step
-Q3:as a good practice, should you rename the applied steps?
-A3:no

[brishtibheja]

even if you didn't know about this behaviour, you could've guessed this is possible to do with conditionals like {{^c1}}...{{/c1}}

[DRudel]

Using cloze references and conditionals does work as well when designing templates because it is easier to limit yourself on the number of fields you are using than the number of references.

[MNastri]

even if you didn't know about this behaviour, you could've guessed this is possible to do with conditionals like {{^c1}}...{{/c1}}

I don't understand what you're proposing.

In my example above I just use {{cloze:Q1}}{{cloze:Q2}}{{cloze:Q3}} in my front/back template and that's enough to create separate 3 cards that are siblings for me to review. I don't think there's a simpler way to achieve the same result.

Maybe you want me to use the {{^FieldName}}...{{/FieldName}} syntax in the basic note type, but that is simply worse.
You'd need a front/back template with something like this in it
{{^Q2}}{{^Q3}}{{Q1}}{{A1}}{{/Q3}}{{/Q2}}
{{^Q1}}{{^Q3}}{{Q2}}{{A2}}{{/Q3}}{{/Q1}}
{{^Q1}}{{^Q2}}{{Q3}}{{A3}}{{/Q2}}{{/Q1}}
Now I only need one card type, yes, but anything more complex than 3 fields just makes this template impractical (I already use 40 question fields)

Or maybe you want me use it with the cloze tags like {{^c1}}...{{/c1}} but what's the point if it already does that by default? Also you'd need the same verbose code as I just typed above with just one less tag per line (e.g. {{C1}} instead of {{Q1}}{{A1}} in the first line)

So I don't think I understood what you meant.

I love Clozes because you can put the question and answer in the same field instead of each in a separate field and halve the number of fields,
and that Cloze cards are sibling cards instead of having to create and mantain multiple card types to get siblings,

Clozes simplify everything