Re: haddock-2.3.0 literate comments discarded from .lhs input

On Mon, 2009-02-09 at 15:36 +0000, Malcolm Wallace wrote:

Duncan Coutts 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