Allow suffixes on (@)-numbered counters

[dubiousjim]

A common numbering style in academic papers is to number displayed items in groups like this:

(10a) Sample sentence.
(10b) Variant of the preceding.
As (10b) demonstrates, ... But now consider:
(10c) blah blah

Rather than coding this with explicit LaTeX markup, it'd be very useful if Pandoc extended the (@foo)-numbering syntax like this:

(@foo:a) Sample sentence.
(@foo:b) Variant of the preceding.
As (@foo:b) demonstrates, ... But now consider:
(@foo:c) blah blah

The intention is that this would render the same as the preceding displayed block. I'd hope that the post-colon material could also include things like ${}'$, so that I could have (10), (10'), (10''), and so on.

Sorry if this has already been discussed; I wasn't able to find anything relevant on the bugtracker or in pandoc-discuss.

[dubiousjim]

Here is some work towards generating the right output formats.

In LaTeX, one just will generate a enumerate environment as Pandoc normally does, then use:

  \item[(foo)] line

to have a line labeled with (foo).

In HTML, one needs this css:

ol.hard-numbered {
    list-style-type: none;
}
.hard-numbered li:before {
    content: attr(value)'.';
    margin-left: -3.5em;
    padding-right: 0.5em;
    display: inline-block;
    text-align: right;
    width: 3em;
}

then one can do this:

<ol class=hard-numbered>
    <li value="foo">equation</li>
    <li value="bar">equation</li>
</ol>

to get lines labeled with foo. and bar..

[dubiousjim]

I have this implemented (at least the Reader side of it) in a custom version of Pandoc I'm tinkering with. Once it's stable and the Writer side is also implemented, I'll pass on what I've got for consideration. Just thought I should say this in the (unlikely) event someone else may consider working on it simultaneously. The syntax I'm using is:

• (@) and (@tag) work as before
• (@tag@subtag) creates a marker like "10a", where @tag references "10" and @subtag references "10a"
• One can have (@tag|suffix) or (@tag@subtag|suffix), where the inline markdown in suffix is appended to a (new or already-existing) tag marker. (To reference an already-existing subtag construction, you'd just use (@subtag|suffix). Not sure there are good use cases for (@tag@subtag|suffix). That would add a suffix to something like "10b", where "10b" had never before appeared. Anyway, the implementation I wrote permits this.)
• You can also write (@|suffix). That doesn't increment the example counter that gets displayed, it just typesets a bare (suffix). The advantage to doing this in an example list, rather than just writing plain (suffix) ..., is that (@|suffix) will introduce a list item that gets styled the same as, and grouped together with, other surrounding example list items.

I'm keeping track of the needed additional metadata in some additional counters and maps in the parser state. I'm assuming that I can just pass that additional state to Writers that are capable of properly outputing the new markup. To Writers that aren't capable of handling it, then instead of:

(9) example item
(10a) a subitem
(10b) a second subitem
(9*) the first item again with a suffix
(11) a new main item

you'd just get output like:

(9) example item
(10) a subitem
(11) a second subitem
(12) the first item again with a suffix
(13) a new main item

[jgm]

+++ dubiousjim [Jul 17 14 06:12 ]:

I'm keeping track of the needed additional metadata in some additional counters and maps in the parser state.

Parser state is local to the parser. Everything the writers need must be put into the Pandoc AST.

            (reader)       (writer)
 source format ==> Pandoc AST ==> output

Note that example lists are not first-class citizens in the Pandoc AST. (See Text.Pandoc.Definition.) The markdown reader converts them to regular ordered lists at the end of parsing. All the writers see is an ordered list. And the problem is then that the OrderedList type doesn't contain any way to mark all the distinctions you want.

[dubiousjim]

I feared that it might be so, but I thought I'd just work on the Reader side for now and worry about it later. I was trying to make changes only to a single package, without having to also customize pandoc-types.