John MacFarlane

Hint: your construct is like a fenced code block (opening line delimiter, contents, closing line delimiter). So you should be able to mimic the treatment of FencedCode.

Here's a short demonstration of the issue: ``` % pandoc -s -f csljson -t csljson [ { "id": "a", "note": "a: b c" } ] ^D [ { "a": "b...

Pure citeproc repro: ``` λ> decode "[{\"id\":\"a\",\"note\":\"a: b c\"}]" :: Maybe [Reference (CslJson Text)] Just [Reference {referenceId = ItemId {unItemId = "a"}, referenceType = "", referenceDisambiguation = Nothing, referenceVariables =...

OK, I see that this is due to the following code in Citeproc.Types (l. 872): ``` haskell | k == "note" = do t' Reference i' t'' d' (M.insert "note"...

ALso https://citeproc-js.readthedocs.io/en/latest/csl-json/markup.html#cheater-syntax-for-odd-fields If we haven't implemented this correctly, we can revisit.

Maybe @denismaier or @bwiernik or @bdarcus can comment. From the linked issue, it sounds as if CSL has added support for something like ``` "custom": {"a": "one", "b": "two"} ```...

Not sure what is best here. The cleanest option would be to add support for `custom` disable `note` parsing. This would have the disadvantage that some people's existing workflows may...

Wish I knew how common it was for pandoc users to use this note-parsing trick, and how common it is to want to use a note field for other purposes.

Following up on this: was "custom" ever added to 1.0?

Collapsing implies grouping. Grouping can cause problems when there are prefixes and suffixes, because it can reorder citations. Hence we are conservative about doing it in these cases. The missing...