Closed sgraf812 closed 10 months ago
It seems that my PR arose out of a misconception about --pre mode; apparently, Pre
is not an actual code style but hands off to NewCode
, but only if the number arguments matches. E.g., literate preprocessors are called like -h file.lhs file.lhs outfile
and this scenario is detected in the options parser.
So when I tried to reproduce an issue with the literate preprocessor, calling lhs2TeX --pre file.lhs -o outfile
actually is a bogus invokation and exercises a completely different code path.
Rather than going through that code path and ultimately crashing in display.select
and inline.select
, I'd rather have it crash early when [Pre,Help] | length n >= 3
did not match.
Closing in favor of #97.
I noticed that
lhs2TeX --pre
would crash as soon as there was an intervening\begin{comment}
or\begin{spec}
, or ... block.I also
removed travis.yml.patch(realised that .travis.yml is very much alive and kicking?) and addeddist-newstyle
to the .gitignore, and bumped thecabal-version
to 2.0autogen-modules
are used.Is there a recommended way to add a regression test? If so, I couldn't find one...
To be precise about what the bug is:
If you put the
eval
orperform
first, you'll instead getwhich sounds a bit like https://github.com/kosmikus/lhs2tex/issues/87, where the error message is triggered by
My patch seems to fix matters for the reproducer above; not sure about #87.