[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Bug: src code blocks of type compilation-minor don't work when g
From: |
Nick Dokos |
Subject: |
Re: [O] 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/)] |
Date: |
Fri, 01 Feb 2019 14:04:27 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
John Ciolfi <address@hidden> 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