Basic+Reversed cards - Githubissues

memeplex commented 3 years ago

Hey, what about supporting basic+reversed cards? I like your approach of adding the less possible metadata to org nodes, since that way my notes are the same than my cards. basic+reversed only requires an extra boolean annotation, but no special headings.

memeplex commented 3 years ago

Thinking about it, specially now that I realize that you sync everything, why not leveraging tags in the notes to be exported? By default they are not required but say if a flag (as a prefix argument) is passed to the sync methods it will only work on cards tagged as :anki: or :anki-double:. These tags won't be passed to the deck, they just act as filters and type selectors. Or maybe the flag is not even necessary since it's quite easy to set an :anki: tag for the entire file.

I think this is a complement to your non-invasive approach even if it might not seem so at first sight. Because not allowing to filter may become invasive, forcing one to create files that only contain notes. Instead by allowing to filter one is free to create more complex notes and only export the headings that see fit. By keeping all this optional your initial scenario is still supported.

What do you think?

eyeinsky commented 3 years ago

I'm piled up at work atm but this sounds like a reasonable idea :), will add it when there is more time.

I guess there should be a file-global flag to affect all entries in a file (to make them basic+reversed instead of the regular basic) and also customizable variable to affect all entries in all files as well?

memeplex commented 3 years ago

Yes, see my latest edit, I added something about a file level flag. I might help with this, I'm also pretty busy right now, but I'll find the time.

eyeinsky commented 3 years ago

Regarding filtering there is the ANKI_MATCH file-global/in-buffer setting for that (in-buffer setting appears to be the correct term). I think you might be able to achieve what you want with tags through that. It re-uses syntax for org-map-entries for filtering.

memeplex commented 3 years ago

Ok, didn't know of that, I'll read the code later, thanks!

eyeinsky commented 3 years ago

Just two more notes :)

ANKI_DECK was added starting from this comment in issue #11, there might be some relevant discussion there
the match syntax for org-map-entries isn't very well documented even in the official docs I linked (imo), but it says it can filter by tags ("MATCH is a tags/property/TODO match"). If you figure it out and have time then do drop notes here too -- these could be added to the readme.

gsingh93 commented 3 years ago

Regarding the filtering, I got it working by putting #+ANKI_MATCH: +anki at the top of the file and adding (setq org-tags-exclude-from-inheritance '("anki")) to my emacs configuration to avoid subheadings from being matched if a parent heading had the :anki: tag. Although the anki tag now shows up as a tag on the Anki note which I didn't want, but it's not a big deal.

It would be nice though to support other card types like reversed, or card types with other fields.

eyeinsky commented 3 years ago

@memeplex @gsingh93 Regarding filtering notes: what if the better solution to selectively sync entries would be to sync entries one by on the first time and then have a command org-anki-update-all? This would update all cards that already have an ID, but won't add any new ones.

This is better than syncing entries selectively via tags because using tags creates issues:

you probably don't want the tag(s) that you use for filtering to be synced to anki (what @gsingh93 said above)
whatever tag inheritance strategy you use will interfere with both filtering and also which tags to sync -- it will be complicated to get it right

What do you think?

eyeinsky commented 3 years ago

Made PR to be tested #26

gsingh93 commented 3 years ago

I like that solution for selectively syncing, it might be worth it to create a separate issue to track it to keep this one just focused on the note type. (EDIT: I created https://github.com/eyeinsky/org-anki/issues/27)

On the note type, I wonder instead of having the fields hardcoded to "Front" and "Back" (as I see from the PR), we could just take the first two fields of the note type, regardless of name. Or we could have an optional property that lets the user choose which two fields can be taken to be the heading and the content. I have various decks (some created by me, some created by others and extended by me) that have two primary fields but they're not named "Front" and "Back". I don't think this suggestion needs to block the existing note type PR though, that's already very useful as is.

eyeinsky commented 3 years ago

@gsingh93 which other field names would you like to have? The linux Anki I'm using has Front and Back for all "Basic" variants and just "Text" for Cloze. (I'm probably missing some context, could you elaborate.)

gsingh93 commented 3 years ago

Yea, but there are some decks I've downloaded from AnkiWeb that have notes with two fields like "Name"/"Description", "Word"/"Translation", etc. I could go and rename these fields if I wanted to extend those decks, but it would be convenient to just specify those are the fields I want to be considered the same as "Front" and "Back"

eyeinsky commented 3 years ago

@gsingh93 I've added the feature of custom field names in this PR #29, see if it works for your use case.

gsingh93 commented 3 years ago

That should work for my use case, thanks!

eyeinsky commented 3 years ago

This issue should now be entirely fixed:

change default node type by property or customize org-anki-default-note-type #24
selective synchronization by first using org-anki-sync-entry on every entry, then later using org-anki-update-all to update only the org entries that are already synced (= have ANKI_NOTE_ID set) #26
add new note types (= model names) or change field names for existing models by customizing org-anki-model-fields or using the helper org-anki-add-model #29

memeplex commented 3 years ago

Thank you very much!!!

eyeinsky / org-anki

Basic+Reversed cards #24