haddock-2.3.0 literate comments discarded from .lhs input

[Duncan Coutts]

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.

Yep :-)

> > 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
Haskell.

> > 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?

Duncan