Context
Sibling issue to dbosk/didactic#24. A stray _minted/ cache directory
anywhere on the TeX search path (there: a didactic clone installed in
~/texmf with in-place-built docs) makes minted v3 skip creating the
project-local _minted/; latexminted batch then crashes with
FileNotFoundError writing <project>/_minted/<hash>.highlight.minted,
and every listing in the PDF silently renders as a literal red
<MINTED> placeholder.
Observation
Any project building PDFs through the shared rules is exposed:
tex.mk's %.pdf: %.tex recipes (and noweb.mk's NOWEAVE.pdf,
which invokes latexmk directly) run latexmk without ensuring the minted
cache directory exists. Whether a given machine breaks depends on
whether some unrelated _minted/ is visible to kpathsea — a
hard-to-diagnose, machine-dependent failure.
Why it matters
One line in the shared makefiles immunises every project at once,
instead of each project rediscovering the failure and patching its own
Makefile (as dbosk/vim-noweb did with mkdir -p _minted before
latexmk).
Evidence
From the affected project's log:
(/home/dbosk/texmf/tex/latex/didactic/_minted/default.style.minted)
...
FileNotFoundError: [Errno 2] No such file or directory:
'/home/dbosk/.vim/plugged/vim-noweb/_minted/637CE...highlight.minted'
Verified fix: creating _minted/ before latexmk makes latexminted batch write its highlight cache and all listings render again.
Environment: TeX Live 2025, minted v3.7.0, latexrestricted 0.6.2.
Suggested follow-up
Add mkdir -p for the minted cache directory to the PDF recipes —
tex.mk's %.pdf ${TEX_OUTDIR}/%.pdf: %.tex (and the .dtx variant),
and noweb.mk's NOWEAVE.pdf — before the latexmk invocation. Note
that with -output-directory=${TEX_OUTDIR} minted v3 auto-detects the
output directory, so the cache dir should be created where minted will
look for it (${TEX_OUTDIR}/_minted when an output directory is in
use, ./_minted otherwise). Harmless when minted is unused: an empty
directory.
Once minted fixes the underlying behaviour upstream (trusting a
kpsewhich-found _minted/ and then not creating the local one), the
mkdir can be dropped again.
Context
Sibling issue to dbosk/didactic#24. A stray
_minted/cache directoryanywhere on the TeX search path (there: a didactic clone installed in
~/texmfwith in-place-built docs) makes minted v3 skip creating theproject-local
_minted/;latexminted batchthen crashes withFileNotFoundErrorwriting<project>/_minted/<hash>.highlight.minted,and every listing in the PDF silently renders as a literal red
<MINTED>placeholder.Observation
Any project building PDFs through the shared rules is exposed:
tex.mk's%.pdf: %.texrecipes (andnoweb.mk'sNOWEAVE.pdf,which invokes latexmk directly) run latexmk without ensuring the minted
cache directory exists. Whether a given machine breaks depends on
whether some unrelated
_minted/is visible to kpathsea — ahard-to-diagnose, machine-dependent failure.
Why it matters
One line in the shared makefiles immunises every project at once,
instead of each project rediscovering the failure and patching its own
Makefile (as dbosk/vim-noweb did with
mkdir -p _mintedbeforelatexmk).
Evidence
From the affected project's log:
Verified fix: creating
_minted/before latexmk makeslatexminted batchwrite its highlight cache and all listings render again.Environment: TeX Live 2025, minted v3.7.0, latexrestricted 0.6.2.
Suggested follow-up
Add
mkdir -pfor the minted cache directory to the PDF recipes —tex.mk's%.pdf ${TEX_OUTDIR}/%.pdf: %.tex(and the.dtxvariant),and
noweb.mk'sNOWEAVE.pdf— before the latexmk invocation. Notethat with
-output-directory=${TEX_OUTDIR}minted v3 auto-detects theoutput directory, so the cache dir should be created where minted will
look for it (
${TEX_OUTDIR}/_mintedwhen an output directory is inuse,
./_mintedotherwise). Harmless when minted is unused: an emptydirectory.
Once minted fixes the underlying behaviour upstream (trusting a
kpsewhich-found
_minted/and then not creating the local one), themkdir can be dropped again.