Obsidian_to_Anki v3.4.0 - a feature-rich plugin that allows you to add notes from Obsidian to Anki

No, the script won’t save global tags across files - they’re file-specific.

Then what is so Global about them?

Ah, maybe I should rename them to FILE TAGS then. That probably makes more sense. I’ll do that quickly - check for v1.1.1

Ok, edited the release to have them be FILE TAGS, which should hopefully lessen the confusion for future users.

@Pseudonium: yes, that’s good.
Then my last question is: what is the difference between tags and file tags?
I almost feel we have come full circle, although that will depend on your explanation of this last question.

So say you have a file whose notes are all to do with maths. As a very silly example:

TARGET DECK
Mathematics

START
Basic
1 + 1
Back: 2
Tags: Addition
END

START
Basic
1 + 2
Back: 3
Tags: Addition
END

START
Basic
1 + 3
Back: 4
Tags: Addition
END

START
Basic
1 + 4
Back: 5
Tags: Addition
END

START
Basic
1 + 5
Back: 6
Tags: Addition
END

START
Basic
1 + 6
Back: 7
Tags: Addition
END

As you can see, you have to repeat that ‘Tags: Addition’ line several times.
What FILE TAGS allow you to do is write the above as:

TARGET DECK
Mathematics
FILE TAGS
Addition

START
Basic
1 + 1
Back: 2
END

START
Basic
1 + 2
Back: 3
END

START
Basic
1 + 3
Back: 4
END

START
Basic
1 + 4
Back: 5
END

START
Basic
1 + 5
Back: 6
END

START
Basic
1 + 6
Back: 7
END

So, it saves typing out the same line for a bunch of related notes.

@Pseudonium: so, file tag is meant to automatically add the tag “Addition” to different Anki cards that all originate from the same .md file !!

If this is correct, then that is where our misunderstanding originates. The reason for that is that the Anki cards I will produce from Obsidian will be based on “atomic” notes/files from each of which I can/will only produce a single card. So, in my mind your script was for 1 Anki card per zettel, but that is not necessarily the case.

So, the misunderstanding was entirely caused by my blinkered mindset that refused to throw off the blinkers until you confronted me with a primary school exercise.

If I am right in all this (please confirm if true) then I apologise for driving you nuts, but hopefully it can serve others to get a clear picture without bothering you like this.
Mea culpa :blush:

@Klaas No worries, I can definitely see how GLOBAL TAGS and others led to the confusion.

CGP Grey has a nice saying related to this - to paraphrase, he talks about how “people systematically underestimate how different human minds are”. So in my mind it was obvious that you’d want more than one note per file, and it was equally as obvious in yours that you’d want a single note in an atomic file!

3 Likes

@Pseudonium: absolutely right.

I do want to thank you once more for your help, and esp. your patience with this blinkered Obsidianist.

I don’t know if you saw it but I did praise your script in the other thread yesterday.

1 Like

@Klaas Yes I did see it, thank you for your kind words!

I think I might introduce some more options to configure the script in a future update, so you could change START END to start end or even s e. That might help with making the script make more sense for the user.

Also, for use cases where you’re making relatively simple cards for each file, I might see if I can implement some sort of ‘inline card’ syntax, since that’s more convenient than having to have an entire block every time.

1 Like

@Pseudonium: re you 1st para, I actually prefer START to “start” because it allows me to distinguish easily the main body of text from the Anki card-designated bit.

Re your 2nd para, I think that’s a good idea !

Regarding my first para, it would be user-configurable! So it would still remain START and END as default, but the user could change it to suit their style.

@Pseudonium: perfect !

Update - v1.2 just released, which makes the script syntax more configurable and adds support for inline notes. For more info, see the Github page.

@Pseudonium I am a huge fan of your work.

A while back I was thinking of implemeting something similar, I am glad you did this.

I have two suggestions.

  1. Can you implement a crude mode where each header is turned into a question and the text within that header is used as back of the card?
# question 1
reply1

## question 2
reply2 

What you have implemented right now allows for explicit\curated creation of flashcards. Which is very nice.
The crude mode allows a rough but faster convertion of your obsidian vault into flashcards.

  1. When we will have an API, it will great if you could take the list of notes that match a search within obsidian, save it in a file, and use that file to pick which notes to process.

If I have some time in the future I’ll try to help you with this.

2 Likes

@WhiteNoise Thanks! I’m happy you find it useful.

With regards to your suggestions:

  1. I think inline notes go partially in the direction of making adding notes simple-ish. For example, if you had Basic = B, Begin Inline Note as si, and End Inline Note as ei, you could do the crude notes as si [B] question back: answer ei

However, I get how it’s obviously much easier to just do # question answer.

I think I might be able to implement something like this if the script takes in a ‘crude’-formatted file, modified it to fit the script syntax, and then ran the script over it normally. Would that be fine? I’m just worried about adding this as a core feature, in case anyone uses headers inside a regular card and experiences issues.

  1. I might be able to implement this if it was an Anki-style search query, since there’s an AnkiConnect API for that. My worry about pulling the notes into one file is that I either move them from their original file or create duplicates - I could instead append a line after the {End Note}, something like ‘EDIT THIS NOTE’. You could then ctrl-f to find that line.

I did think of another feature that could help people wanting to do custom syntax for notes - an option in the config file for each note type that specifies a regular expression to match cards for that note type, with capturing groups for the different fields.
So, for example, your one could be:
#+ (<question>.*) \n (<reply>.*)
^ that assumes the reply is a single line.

Thinking about this more, this could be pretty powerful - e.g. you could use a remnote-style front::back by defining an appropriate regular expression! I’ll think about adding this to the next update.

I agree with both your points here.

I am sorry I was not clear here. I mean you get a list of files from obsidian query and then threat each of these files individually like I think you currently do with a directory.

This looks pretty powerful. However, simple users might get confused by all this flexibility. and I still think in the case of the crude transformation the two-step process you proposed erlier makes more sense.

I might keep a list of useful regexps in a file on the repository, with example usage for each. So, the users wouldn’t necessarily have to understand regex, just copy-paste a template they like the look of into the appropriate section.

If I frame things in regexp under the hood, it’ll be easier to implement things like a crude mode (which just corresponds to a particular regexp for a particular note-type, and could be hard-coded into the script itself)

Specifically, I could add two modes in the next update - —crude, which implements your particular example, and —regexp, which only uses user-defined regexp

Just to clarify - the ‘replies’ in crude mode are expected to be one line, or run over multiple lines (not in a single-line wrap kind of way, but actual newline kind of way)?

2 Likes

Hello, and thank you for the plugin.
But I have encountered some issue with TARGET DECK, I have been adding cards to one deck, and needed to use a different deck for another subject, in the file where my cards are defined I setup TARGET DECK to the new one, but it’s still pushing the cards to the old deck that is defined in another .md file, any suggestions?

@sunset-rise Could you raise this as an issue on the GitHub? It’ll be easier to resolve from there.