Feature: recursive citeproc?

[jdutant]

There some demand for recursive citations, i.e. handling \cite commands within the bibliographies themselves, usually in the BibTeX note field. See this exchange on pandoc-discuss. Would you be interested in a PR adding this?

I've written a recursive citeproc filter that we use in the journal dialectica. I'm considering updating it for Quarto, but I'd be glad to contribute to section-bibliographies and multibib and use one of these instead.

I'd try to make the addition as lightweight as possible when no recursion is needed by first scanning the first citeproc pass's output with a filter {{ Citation = function(elem) has_citations = true end }}.

[tarleb]

Sure, I'd be open to add that. Interesting that something like this exists, very uncommon in the stem fields.

[jdutant]

Thanks. I've now updated recursive-citeproc to make use of modern Pandoc - back then we didn't have pandoc.utils.citeproc and pandoc.utils.references! I'll see if I can integrate that in these filters.

[bcdavasconcelos]

I noticed that multiple-bibliographies does not process citations in the nocite field. Maybe the solution in both cases (multiple-bibliographies and section-bibliographies) will be the same? That is, adding the nocite citations to the table of citations in line for processing and letting nature run its course (?)

[jdutant]

Not that straightforward, unfortunately! For each section, you need to produce a draft biblio; if that biblio introduces new citations, then you should add these citations to nocite (in the tmp doc used to produce the section biblio) and produce a biblio again (where there are now entries). But this may introduce yet new citations, so you need to start again. Only once you've produce a biblio that contains all the entries that may be cited, cited within citations, cited within citations of citations, etc, you can ship it to citeproc to turn the citations appearing in the biblio into text.

A separate topic is how, if at all, this filter should handle nocite. That's worth opening a separate issue: #10.