jgm
Resetting the subsequent status of citations
It is fairly common for notes styles to specify that a subsequent citation to a work should use a shortened form only if the citation recurs within a single chapter of a book. For example, the MHRA Style Guide, sect. 7.12:
In a monograph or thesis, treat each chapter independently for this purpose. That is, give a full reference for a source at its first mention in the chapter, and shortened references later in that chapter. If it occurs again in a later chapter, give the full reference again at its first mention there.
This would result in:
# Chapter 1
Contextualists accept disagreement.[1]
[1] John MacFarlane, *Assessment Sensitivity* (Oxford, 2014), 12.
# Chapter 2
MacFarlane describes the Reflexive Truth Rule as 'incomplete'.[1] He emends it using a clearer definition of retraction.[2]
[1] John MacFarlane, *Assessment Sensitivity* (Oxford, 2014), 108.
[2] MacFarlane, *Assessment Sensitivity*, 108–10.
There have been a few suggestions for dealing with this in https://github.com/jgm/pandoc/discussions/9999, but none of them quite give the expected results when a combined bibliography is also necessary.
The ideal solution would be for citeproc to reset the subsequent status of citations every time the processor comes across the heading level corresponding to the top-level-division option. Alternatively, the user could reset it manually using a div/span with a certain class, which would also give a filter the opportunity to insert this before headings or other elements.
citeproc itself knows nothing about headings or other elements of document structure. It just takes in a list of citations and references and produces formatted citations and bibliography.
https://github.com/jgm/citeproc/blob/master/src/Citeproc.hs#L25-L33
One way to do this would be to add a constructor for Citation a that says "reset subsequent status." Then pandoc could insert these when needed.
Yes sounds great. But while we're at it: Some styles (e.g. MLA, APA, Chicago Author-Date) allow ibid. or even only a page number for repeated references within a single paragraph. Maybe there could be a similar constructor to "reset ibid. status". This could then be inserted by pandoc automatically at certain structural elements (sections, paragraphs, etc.), or even manually if needed for clarity.
The problem I'm seeing with this is that pandoc shouldn't be responsible for doing things that are supposed to be controlled by a style. So let me revise my earlier suggestion. Instead of a list of Citations, citeproc should be passed a list of Elements (to pick a generic name), each of which can be either a Citation or a structure marker (e.g., Paragraph, Section, Chapter). It would then be possible for CSL styles to indicate that subsequent status should be reset on a new chapter, or that ibid status should be reset on a new paragraph. Of course, this would require modifications to CSL itself. But I don't see how we can handle this in pandoc otherwise -- the decision about when to reset these things is style-dependent.
Thank you again for thinking about this!
You're right that in an ideal world this would be defined by styles. This would work in cases such as MHRA, which list this as a hard requirement. The trouble is that many others (such as Chicago, sect. 13.32) list this practice as desirable but leave it to the discretion of the editor. Since there are no user options in CSL, that would theoretically require duplication of all the Chicago notes styles to make this an option (and there are already more than thirty variants needed to support the 18th edition). This would confuse users of other reference managers, since there is no simple and reliable way to detect chapter divisions in anything other than pandoc.
Would it be possible to provide a way for filters to reset the subsequent status, even if it doesn't seem logical enough to place this directly in the pandoc interface?
I suppose one could argue that Chicago makes this optional precisely because reference managers do not support it. Reading the section again, there is no question that they think repeating the full note in new chapters is desirable, so perhaps CSL users would not expect extra variants for this.
Still, it would require user intervention to define the level of chapter headings, and it would still be useful in this situation to be able to reset it manually in documents with a strange structure.
Actually, I remember some discussions about this when we were planning a future CSL version (think it was either on github or on the discourse forum). The trouble is that CSL is supposed to be format agnostic and in some environments the citation processor can be more tightly integrated than in others. I guess it should be at least possible to make some sort of structural information available to citeproc in pandoc or in latex, but with the word+zotero combination that won't work. (Although technically, it should be posssible. The Citavi reference manager has these features, but it doesn't use CSL and its word plugin is based on a different plugin architecture.) So, in Word it's just a list of elements with no indicators of structur or other reset markers.
Regarding this:
Instead of a list of Citations, citeproc should be passed a list of Elements (to pick a generic name), each of which can be either a Citation or a structure marker (e.g., Paragraph, Section, Chapter). It would then be possible for CSL styles to indicate that subsequent status should be reset on a new chapter, or that ibid status should be reset on a new paragraph. Of course, this would require modifications to CSL itself.
Maybe this decision does not necessarily be made in a style. Could also be some sort of option passed to processor, similar to default-locale. I think some decisions might well be document or publisher specific.
Can you remind me what the CSL elements are that are sensitive to subsequent status?
@position on cs:if or cs:else
Gesendet von Outlook für Androidhttps://aka.ms/AAb9ysg
From: John MacFarlane @.> Sent: Thursday, July 24, 2025 6:39:35 PM To: jgm/citeproc @.> Cc: Maier, Denis Christian (UB) @.>; Comment @.> Subject: Re: [jgm/citeproc] Resetting the subsequent status of citations (Issue #160)
[https://avatars.githubusercontent.com/u/3044?s=20&v=4]jgm left a comment (jgm/citeproc#160)https://github.com/jgm/citeproc/issues/160#issuecomment-3114133829
Can you remind me what the CSL elements are that are sensitive to subsequent status?
— Reply to this email directly, view it on GitHubhttps://github.com/jgm/citeproc/issues/160#issuecomment-3114133829, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABDTWJTCHYSJODX7LGIXRYD3KED4PAVCNFSM6AAAAACBBLVGMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMJUGEZTGOBSHE. You are receiving this because you commented.Message ID: @.***>
Note to self: it would suffice to empty out stateNoteMap and stateLastCitedMap. That would reset all subsequent/ibid calculations. If something more fine-grained were needed, e.g. resetting ibid but not subsequent, that would be more difficult. In principle information about when to reset could be communicated to citeproc with an additional field on Citation, without modifying the citeproc interface too much. Pandoc would then have to change the way it generates the list of citations to ensure that the "reset subsequent" field was set on the first citation in any new chapter.
I think resetting ibid but not subsequent might be needed indeed. Need to think about specific examples but it doesn't sound unlikely at all that someone might want to do this.
Gesendet von Outlook für Androidhttps://aka.ms/AAb9ysg
From: John MacFarlane @.> Sent: Thursday, July 24, 2025 8:55:18 PM To: jgm/citeproc @.> Cc: Maier, Denis Christian (UB) @.>; Comment @.> Subject: Re: [jgm/citeproc] Resetting the subsequent status of citations (Issue #160)
[https://avatars.githubusercontent.com/u/3044?s=20&v=4]jgm left a comment (jgm/citeproc#160)https://github.com/jgm/citeproc/issues/160#issuecomment-3114525126
Note to self: it would suffice to empty out stateNoteMap and stateLastCitedMap. That would reset all subsequent/ibid calculations. If something more fine-grained were needed, e.g. resetting ibid but not subsequent, that would be more difficult. In principle information about when to reset could be communicated to citeproc with an additional field on Citation, without modifying the citeproc interface too much. Pandoc would then have to change the way it generates the list of citations to ensure that the "reset subsequent" field was set on the first citation in any new chapter.
— Reply to this email directly, view it on GitHubhttps://github.com/jgm/citeproc/issues/160#issuecomment-3114525126, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABDTWJR3MCGSJA25SPFXKYD3KETZNAVCNFSM6AAAAACBBLVGMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMJUGUZDKMJSGY. You are receiving this because you commented.Message ID: @.***>
Can you remind me what the CSL elements are that are sensitive to subsequent status?
This is all in the position attribute. As you suggest, it would simply need to be reset to first at each chapter division to meet typical requirements.
In response to @denismaier's query, an example of where it might be desirable to reset ibid is also found in MHRA §7.12:
The term ‘ibid.’ should be used very sparingly and limited to those situations where there is no possibility of confusion, such as after a second reference which is separated from its predecessor by no more than four lines of typescript.
One way to automate something approximating this guidance might be to reset a position of ibid or ibid-with-locator to subsequent at each paragraph break.
The position is calculated by getPosition, based on the citation group number, the note number if present, and the item's position in the citation. Much of the calculation depends on looking up the item's id in a map that records where each id was last cited. Emptying that data structure will have the effect of a fresh start for all position calculations. So, that one is pretty easy. Resetting ibid without resetting subsequent would require changing the values in this map rather than emptying it. It would probably suffice to change the map's "previous note number" to Nothing and its "previous group number" to some negative number.
I don't think the heuristic you suggest, resetting ibid at each paragraph boundary, will work well. In a piece of writing that is discussing a single work for a long time, you will have ibids throughout (as long as they are relatively close together); it would be quite strange and wrong, I think, to reset the ibid at paragraph boundaries if the same work is being cited near the end of one paragraph and near the beginning of the next.
So, I'm not sure I see a good way of automating this guidance. Given that, and given the complexity of handling the ibid, I'm somewhat inclined just to implement the subsequent. This could be fully automated (requiring no filters), since I think we can assume that subsequent status should always be reset with a new chapter.
Very true: that could produce odd results. The use of ibid. is becoming increasingly rare anyway and I'm not sure that's it's worth spending much time on it.
Not sure about this. Ibid is becoming rare in note styles, at least in English, not so much in German.
Also, Chicago author date, MLA and APA all require to use only page numbers for references to the same item in a single paragraph. Currently, this has to be done manually, as CSL can't handle it. (So, the term ibid is not used here, but it's the same thing.)
But, of course, this is not set in stone and it might make sense to not reset at paragraph boundaries. That's why a manual way to reset ibid might be useful. (Also, in some cases an author might want to mix manual citations with automic citations, say for references to classical or sacred works.)
Gesendet von Outlook für Androidhttps://aka.ms/AAb9ysg
From: Andrew Dunning @.> Sent: Friday, July 25, 2025 8:39:20 AM To: jgm/citeproc @.> Cc: Maier, Denis Christian (UB) @.>; Mention @.> Subject: Re: [jgm/citeproc] Resetting the subsequent status of citations (Issue #160)
[https://avatars.githubusercontent.com/u/1084407?s=20&v=4]adunning left a comment (jgm/citeproc#160)https://github.com/jgm/citeproc/issues/160#issuecomment-3116587302
Very true: that could produce odd results. The use of ibid. is becoming increasingly rare anyway and I'm not sure that's it's worth spending much time on it.
— Reply to this email directly, view it on GitHubhttps://github.com/jgm/citeproc/issues/160#issuecomment-3116587302, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABDTWJUMAS65SLYQONEI3BD3KHGJRAVCNFSM6AAAAACBBLVGMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMJWGU4DOMZQGI. You are receiving this because you were mentioned.Message ID: @.***>
@denismaier Perhaps it would be worth starting a separate issue (or discussion on https://discourse.citationstyles.org) to sort out the issues involved with using ibid. in CSL and potential ways to solve them?
The issue160 branch contains code adding citationResetPosition.
So far no tests and no pandoc integration.
It seems a bit weird to have this global processing instruction (rest positions for all items) as a field of a Citation. However, this is necessary if we want to keep the interface the same (pass citeproc a list of Citations). The alternative would be to pass citeproc a list of processing instructions, which could be either "here's a Citation" or "reset position information."
Beginnings of pandoc changes in pandoc branch reset-position.
However, I have run into a problem. In the Citeproc module pandoc actually doesn't know whether the top-level headers correspond to sections or chapters. --top-level-division is a writer option and hence not available yet in an AST -> AST filter. We could make this sensitive to a class or attribute on headers, e.g. {.reset-citation-positions}. This could be added be a filter or manually.
OK, you can now try some working code in the pandoc reset-position branch.
To reset citations
# My chapter heading {.reset-citation-positions}
We could alternatively use something like reset-citation-positions=true, maybe that's better?
I haven't added tests or documentation for this feature, but I did test it informally and it seems to work.
A few existing tests fail for reasons I don't quite understand; ~~it would be good for someone to have a look.~~ (It's a bug in my code.)
OK, the code in reset-position branch now works, and I've added a test case and documentation. Feel free to check it out.