Support for multiple lines in card front

[nyxkn]

Is it possible to have the front of the card contain multiple lines?

Since the front is generated from the header, this seems to be limited to one line only. Is multi-line support for the front something that's been thought about before?
I saw that this was briefly touched upon in issue 32.

Not sure how this could best be implemented syntax-wise. Something like what anki-editor does might make the tree a lot messier.
Maybe using a block or a drawer for the extra lines? For example:

* front - first line
  #+BEGIN_FRONT
  front - second line
  more front
  #+END_FRONT
  back content

[eyeinsky]

The example you give I have thought about as well, it goes something like this: search for blocks in org entry content for both back and front -- if any are present then use them instead.

May I ask what is your use case? If you just want long text in the card front then a long line in org mode will be wrapped in Anki's html (it won't overflow). But if you want e.g bullet lists in card front, then yes that seems like a valid use case.

[nyxkn]

Yeah the optional blocks sounds like a clean way of going about this.

I wouldn't say this feature is essential. It's just more of a convenience thing so one can have an easier time formatting the front for aesthetic purposes. Sometimes I'd have a question in the front but I also want to add a sort of subtitle or hint and that just looks nicer on a new line.

The whole header is always wrapped in one big <p> tag, so even adding line breaks is a bit clumsy. The \\ syntax for line breaks doesn't seem to work on headers. But I did find that you can add explicit html like this:
* front first line @@html:<br>@@ front second line

Also for the sake of documenting my findings:
Mathjax also works in the header with \( and \[ blocks. \[ blocks end up on a newline which is neat. And all of the inline org markup syntax is also picked up.

So really this would only be for prettier newlines and, as you mention, lists.

[orgtre]

I'd say this is an essential feature which would make org-anki a much closer alternative to anki-editor. In my setup, my org notes collections double as local wikis and usually the front is several lines of setup and context, which may include, lists, equations, images, etc. It is important that this looks nice in org too, not only after it is exported to Anki.

For example, the front might include the formulation of a math problem with explanations of the setup/notation, a citation to the paper where it originates, and then the question of how to solve it. Usually much of this is transcluded from a question which asks what the setup/model is in this and that paper.

In my fork of anki-editor the logic is currently something like the following:

• if the note type has two fields and there is no subheading, map the heading to the first field and the content to the second field
• if the note type has two fields and there is a subheading matching one of the fields, map the content before the subheading to the other field and the content below the subheading to the matching field
• if the note type has two fields and each field matches a subheading, map the content accordingly
• if the note type has more than two fields, at most one field can be omitted in the org note, in which case the content before the first subheading is mapped to it; for each of the remaining fields there has to be a subheading matching it whose content is mapped to the field
• else complain

Hope this can help.

[eyeinsky]

@orgtre The logic you describe (look for subheadings that are titled with the field name for the note type) sounds very reasonable.

I wonder if when note front and back are both subheadings themselves it would make sense to include entire subtrees for their content -- not just until the next heading? E.g the following:

* Top heading
** Front
front content
*** Subheading currently not included in front
but should it be included?
** Back
something back

[orgtre]

@eyeinsky Yes, that would be desirable I think. It should also not be very difficult to implement.

[eyeinsky]

This is now in latest master, tagged as version v2.0.0.