haddock-2.3.0 literate comments discarded from .lhs input
duncan.coutts at worc.ox.ac.uk
Mon Feb 9 19:34:52 EST 2009
On Mon, 2009-02-09 at 15:36 +0000, Malcolm Wallace wrote:
> Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> > Someone was complaining the other day that the hscolour output
> > run on the result of happy is not really readable,
> To clarify, what he said was that hscolouring Happy output did not
> _enhance_ its readability. In other words, you can put lipstick on a
> pig, but it's still a pig.
> > but then it's not
> > clear if running it on the happy input would be any better.
> Try it! I reckon it looks pretty good actually. Lexically, the
> difference between Happy and H'98 sources is negligible.
Aye. The difficulty is we have to have a list of which pre-processors to
run or not run before using hscolour. Or perhaps we just hope that all
original sources are ok going through hscolour, even if they're not
> > For the particular case of .lhs and cpp, I hope we'd get better
> > hscolour output by not running unlit or cpp first. Malcolm says it'll
> > at least do something. So it seems worth checking which ends up
> > looking more useful.
> It seems likely that preserving the literate comments is the sensible
> thing to do, since we are linking together documentation here
> (haddock/source). HsColour has -lit and -lit-tex options, to avoid
> colouring the literate comments from a .lhs.
I'm not sure what we can do here. We don't know if the file is bird
track or tex style. Can we get away with always using one option?
More information about the cabal-devel