Re: Bug: src code blocks of type compilation-minor don't work when generating PDF [9.1.14 (9.1.14-dist @ /path/to/org/install/emacs/site-lisp/org/)]

[Nick Dokos <ndokos@gmail.com>]

John Ciolfi <ciolfi@mathworks.com> writes:

> Hi
>
> Using following
>
>   emacs -q --batch -L /path/to/org/install/emacs/site-lisp/org -l my-org-to-pdf.el
>
> the generated PDF is incorrect. The "compilation-minor" code block gets
> replaced with the "c" code block, i.e. the c code block is
> duplicated. If you generate HTML all is good. Running org-lint doesn't
> indicate that one cannot use compilation-minor code blocks.

Hi John,

Given that the produced foo.tex file looks correct, it seems that
since minted does not know what to do with the "compilation-minor"
"language", it goes off a cliff. If you compile it by hand:

   pdflatex --shell-escape foo.tex

it produces an error message:

,----
| (./foo.out.pyg) (./foo.out.pyg) (./foo.toc) (./foo.out.pyg)Error: no
| lexer for alias 'compilation-minor' found system returned with code
| 256 (./foo.out.pyg)
`----

but since it produces a (wrong) PDF, the org exporter does not dig any further.

Changing the language to "c" in the tex file (or in the
source block before re-exporting) produces something a bit better.
Ideally, you'd need to define a lexer for the "compilation-minor" "language",
but that's a minted/pygments project.

Not sure whether it's worth doing anything about this on the org mode side,
but that's not my call.

HTH.

PS. Constantine says "Hi" :-)

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler