frozencache using listing<num> is fragile for final layout

[llimeht]

I recently had the following experience with a journal:

• we wrote our manuscript in LaTeX using minted for some syntax highlighting of code snippets
• the journal wanted a frozencache since they didn't want shell-escapes (that's fair!)
• we gave them the frozencache for the LaTeX file we had submitted
• in putting the article into the journal's prettied up 2-column, tightly typeset form, they moved a figure compared to where it had been in review
• the figure caption contained a \mintinline, therefore the order of all the minted listings had now changed

None of these individual steps was unreasonable, but the outcome is disastrous.

The catch is that once frozen, minted is ignoring the contents of \mintinline{foo}{bar} and just pulls up listing<num>.pygtex based on the minted@pygmentizecounter counter, but that's no longer the right listing.

It's documented that this isn't something that minted's frozencache supports. Once you've frozen it, you're not allowed to reorder the document like that, but at the same time, it's not like the publisher reordering the figure isn't a common and necessary thing to do.

If the cache still used the contents to find the file, the frozencache would be reorderable, and that would solve this issue. I presume that doing so implies hashing the contents, but since that currently relies on shell-escapes, some LaTeX-based way of calculating a hash would be needed; \pdfmdfivesum exists for instance, but I have no idea how portable it is across LaTeX engines.

(For anyone else landing here via a panicked web search, doing quite brutal things to the counter seems to have sorted it for us for now... \addtocounter{minted@pygmentizecounter}{-1} etc. We'll find out how upset that makes the publisher when we return the corrected proofs!)