Cloz: many {{C1::

[emisjerry]

Hi,

Is there any way to insert many {{C1:: in Front?

Thanks.

[kitschpatrol]

I went back and forth during development on whether a series of clozes should increment or share an ID... and I ended up going with the increment.

Just to be clear, a note with Markdown like this:

This note has ~~one~~, ~~two~~, ~~three~~ clozes.

Will yield Anki markup like this when synced via Yanki:

This note has {{c1::one}}, {{c2::two}}, {{c3::three}} clozes.

And you're wondering how to instead get:

This note has {{c1::one}}, {{c1::two}}, {{c1::three}} clozes.

The current short answer is that you can't, and that's just a design decision made in the process of taking a radically reductive approach to coming up with simple mapping between Markdown syntax and Anki functionality.

Potentially open to this, but would have to think of the right syntax... open to suggestions.

[emisjerry]

How about insert an additional numbers, for example (more flexible):

~~{1}one~~ ~~{1}two~~ ~~{2}three~~
or ~~^1one~~ ~~^1two~~ ~~^2three~~ (one number only)
to generate {{c1::one}}} {{c1::two}} {{c2::three}}

or add a new tag for grouping directive, for example:

#cloze-group
~~one~~ ~~two~~ ~~three~~
to generate {{c1::one}}} {{c1::two}} {{c1::three}}

BTW, i've made a introducing Youtube videos about your plugin, maybe you'd be interested:
https://youtu.be/CE6iNxBGBTc
https://youtu.be/DQ9DFKPugpQ

[kitschpatrol]

Thanks Jerry, yes some kind of number prefix probably makes sense.

^ is already used for footnote syntax in Markdown and block syntax in Obsidian, and {} feels very close to Anki syntax, which might be intuitive... or might be confusing since it's close but not identical.

There's already the precedent of using the | pipe character to delimit title metadata in Obsidian wiki links and to specify image dimensions, though I don't love how the | can be mistaken for a 1 or a l. Maybe something like:

~~1|one~~ ~~2|two~~ ~~3|three~~

Also in hindsight I'm not crazy about the _ syntax Yanki uses for cloze hints... I wonder if it would be better to just use | to delimit both the index and the hint...

E.g. instead of:

~~1|one _hint_~~ ~~2|two _another hint_~~ ~~3|three _and another hint_~~

Do something like:

~~1|one|hint~~ ~~2|two|another hint~~ ~~3|three|and another hint~~

Tricky markup like this is kind of antithetical to Yanki's premise of keeping things simple, but I suppose it stays out of the way for 99% of use-cases.

Interested in your thoughts. I'm busy this coming week, but should have some time the following week to implement one of these variations.

---

And not to derail the issue thread, but thanks for sharing the videos, I'll link to them in the readme on the next release!

I need to watch them all the way through, but a couple quick thoughts:

• Using different Anki profiles definitely doesn't hurt, but FWIW Yanki should leave you existing Anki notes / cards alone. (It only operates on notes that match the namespace derived from your vault ID, which you'll see in the note type templates. And there's some extra logic to handle deck name collisions non-destructively.)
• Your TTS integration is very interesting! Yanki can sync embedded assets from Obsidian, so there might be another workflow where the TTS is generated in the flashcard note files in Obsidian via some sort of plugin, and then both the note + audio assets are synced up to Anki via Yanki. Not really better or worse, but it could be nice to have the audio clips in Obsidian as well. And that way you wouldn't have to edit the generated Yanki - * note type templates, which is potentially dangerous... Yanki "owns" these templates in Anki, and might overwrite any changes you've made in the future. (I'll add a note about this to the readme.)
• I agree that generating a bunch of individual note files can kind of be a pain, I've used the obsidian-note-splitter plugin in some cases, or I'll open my Obsidian vault in VS Code to do bulk regex operations. (The joys of having local Markdown files... 😁)
• Adding CSS stylesheets is actually something the lower-level CLI-version of Yanki supports via the yanki style command, which bulk-adds CSS to all of your Yanki - * note types. Maybe I should add a text area in the Yanki Obsidian settings where you can specify custom CSS. All Yanki-generated Anki notes are wrapped in a <div> with a bunch of classes depending on the note type, so it's feasible to write very specific selectors. Also I should flag that there was a bug in previous versions of Yanki Obsidian that was preventing inline CSS via <style> tags from working correctly, but that's been fixed in version 1.1.1, so you can now specify inline styles in your notes in Obsidian, which could pair well with the Templater plugin.

Feel free to DM me on Discord (username kitschpatrol) if you'd like to discuss any questions about Yanki.

[emisjerry]

You're the most serious author I've ever seen replying to a post. 😀

Thank you for your response. If there are more requests, I will ask for them directly.

[kitschpatrol]

I added support for manual cloze numbering in the latest release, 1.3.0.

I initially implemented the |-based approach for both the number and the hint, but it felt kind of messy... so I just went with a very simple leading-number based approach and am keeping the original _emphasis_-based hint syntax.

The markdown:

~~1 first cloze~~ ~~1 second cloze~~ ~~2 third cloze~~

Now yields the following Anki markup:

{{c1::first cloze}} {{c1::second cloze}} {{c2::third cloze}}

There's also (undocumented) tolerance for some variations on the exact format of the cloze number... for example ~~1) cloze~~ will be handled without complaint.

---

The existing behavior of auto-incrementing clozes remains as before. The Markdown:

~~first cloze~~ ~~second cloze~~ ~~third cloze~~

Yields the Anki markup:

{{c1::first cloze}} {{c2::second cloze}} {{c3::third cloze}}

---

The hint syntax is also as before, the Markdown:

~~1 first cloze _first hint_~~

Yields the Anki markup:

{{c1::first cloze::<em>first hint</em>}}

[emisjerry]

Thanks. Can't wait to try it out.