Ok, I’ve “wasted/invested” hours in to this and I simply can get my simple five lines of code to work, reliably. Evertime I think I’ve got it, it breaks.
I’m trying to place this yaml in my document. I’ve tried: putting it in a note, in a template, an ^include(), and a macro. I’m sure I’ve tried other stuff. No matter what I do, Tinderbox thinks it is text and formats it. I’ve also tried having pandoc reference an external .yaml file and I can’t seem to figure out either. I can get it to find the doc, but then it says there is an unsupported reference.
(Some pre-amble: I spend some while discussing this/trying things with Michael).
I believe the YAML works OK if exported as a separate document and used externally as a pandoc input parameter source.
What isn’t clear is where in this highly complex export things are going wrong. From what I’ve seen, I don’t think it is Tinderbox standard export but rather in the complex-plex-preview-without-export process.
I think it important to point out that—current Markdown support notwithstanding—‘Preview’ mode was introduced to allow the use to check HTML [sic] outpour without exporting. Markdown, pandoc, etc., come later in the piece.
To let the community help, I’d request @satikusala provide a ‘minimum viable example’ TBX doc (i.e. as little content as needed to prove all necessary elements) and then we will have a common frame of reference as this is definitely not a simple problem to resolve. It is also unclear that it is even a Tinderbox export problem at this stage, as opposed to optimistic expectations for what preview mode can handle. We need to consider the ROI of additional export complexity here, given that many users don’t use export.
Personally, I sue export and I think the idea proposed is neat, but I’m mindful of the wants/needs of the wider community of Tinderbox users. It may well be that it simply a case of exporting and ‘previewing’ externally, as we did up until v6.
Pro tip: In Tinderbox, it’s often nice to save intermediate results in an attribute, so we can determine just what is going wrong inside a long and complex expression. The same technique can be helpful when testing a tool chain. Break your tool chain in half, and write the results to a file. Look at the file: is it right? If it looks right, pass it to the second half of your tool chain: is the output right?
In this case, you’d have gotten the YAML input you expected, but the expected YAML would not work. That would call your attention to figuring out exactly what YAML was doing.
Yes. I was doing that and you’re right. I was getting YAML errors. I just could not figure out why. The magic answer, two spaces and not one in the YAML file.
As far as I know, Pandoc / Multimarkdown YAML doesn’t need two spaces before or after the colon — at least, it never has while I’ve used it and as far as I can see it’s not mentioned as a requirement in either manual. You need to indent the subsequent lines of multiple line blocks (e.g an author field with more than one author, but not the first line of metadata headers, where one space is fine after the colon (and you don’t need any before it).
According to the Multimarkdown syntax, however, it’s a good idea to put two spaces after the whole line (i.e. as a fake paragraph break) because otherwise more limited processors (e.g. bog standard markdown) may run the lines together.
While not required, I recommend using two spaces at the end of each line of metadata. This will improve the appearance of the metadata section if your document is processed by Markdown instead of MultiMarkdown. (Metadata)
As Tinderbox is using CommonMark, which is less sophisticated than either P or MM, then perhaps this may be what’s happening here?
(Apologies if I’m misunderstood what you’re trying to do here…)
Thanks for the note. I don’t know why, but two space after the colon works, one does not. Note, I’m not using Markdown or CommonMark in this case for HTMLPreview, but Pandoc.
Odd - a single space after the colon works fine in Pandoc for me (outside Tinderbox) — and there’s nothing in the Pandoc manual to suggest that more than one space is required. In fact, one of the examples they give of a metadata block has only one space (Pandoc - Pandoc User’s Guide)
---
title: The document title
author:
- name: Author One
affiliation: University of Somewhere
- name: Author Two
affiliation: University of Nowhere
...
It sounds like something’s going on within Tinderbox, but what, I’ve no idea Does it work with two spaces at the end of the line as an alternative?
I was merely trying to help you sort out where the real problem is (there’s clearly something odd going on somewhere in your chain, because there’s no specified requirement for two spaces after the colon in either Pandoc or Multimarkdown’s use of YAML).
Does it work with two spaces at the end of the line as an alternative?