Closed ghost closed 4 years ago
That's an interesting edge case, I'd restructure your example as
* Name
** First Name :fc:
nothing
** Last Name :fc:
nothing
or use a cloze deletion for it
* Name :fc:
{{nothing}{first name}} {{nothing}{last name}}
From a technical standpoint it wouldn't be hard to allow nested cards by adding a local
to the get-tags
org by adding the fc tags to the list of org tags that are not inherited.
I'm not sure it's a good idea because different (custom) card types might use some of the subheadings (e.g. a "Back" heading in normal, double and text-input cards).
Regarding your sidenote, I'd like to switch from github to sourcehut but I need to rewrite the documentation first (turning it into a website because sourcehut doesn't display org files like github does & changing the installation instructions).
Once that's done, I think I'll keep both repos in sync and add a note to the github readme.
Regarding formulation of flashcards: The main strength of org-fc
over SuperMemo and Anki and literally every other SRS software is that you can create hierarchical relationships between flashcards. This issue gets in the way of that flexibility by forcing you to add boilerplate - an issue that org-drill
has, and which forced me to try org-fc
.
(Sure, Supermemo has a data structure called collections where you can create hierarchical organization, but that's the same as Anki's decks: there's no hierarchical relationship between flashcards, just hierarchical relationship between containers.)
Regarding technical implementation: I'd say directly replacing org-get-tags
with org--get-local-tags
does seem to cause other issues for custom card types and therefore agree that it is a bad idea. Perhaps we can replace the simplistic logic with one that detects whether the card is a custom type or not, and then give an appropriate response.
Since this is a design choice, I leave it up to you to decide how you intend users of org-fc
to create flashcards.
Regarding sourcehut: Do try out the mailing list and the todo functionality of sourcehut. I'd recommend that over collaborating over github any day.
What do you think about the following implementation:
headline-blacklist
that defaults to '("Back")
org-fc-allow-nested-cards
(or (not (org-fc-part-of-entry-p)) org-fc-allow-nested-cards)
This would be more elegant with card types based on eieio classes, then we could ask the parent card object for its blacklisted headings.
I'm glad to hear you prefer sourcehut todo/mailing lists, we can move this discussion to https://lists.sr.ht/~l3kn/org-fc-devel
I'll see if I can complete my rewrite of the docs today (https://www.leonrische.me/fc/), then sourcehut can become the main home of org-fc.
Closing, moved to https://todo.sr.ht/~l3kn/org-fc/1
Here, if you attempt to use
org-fc-normal-init
on the subheading, it states that the "Heading is already a flashcard".This, afaik, is due to this function:
org-get-tags
lists inherited tags, and subheadings inherit the:fc:
tag. However, the subheadings are not flashcards, nor are they specifically part of a flashcard.One way one could fix this is to disable tag inheritance via
(setq org-use-tag-inheritance nil)
, however I think we should do something about this ambiguity..Sidenote 2: Which repo is the "main" one you use: your sourcehut or github?