haddock-2.3.0 literate comments discarded from .lhs input

[Duncan Coutts]

On Sun, 2009-02-08 at 19:18 +0100, Andrea Vezzosi wrote:
> I did work on this and i simplified the code a lot fixing
> inconsistencies and making more explicit what how each component
> contributes to the arguments to haddock.

Much appreciated.

> Aside from this, should we also do the unliting and cpp from Cabal on
> the sources passed to HsColour?

Hmm. I thought it did already :-) Well, I know it runs happy, hsc2hs
etc. Someone was complaining the other day that the hscolour output run
on the result of happy is not really readable, but then it's not clear
if running it on the happy input would be any better.

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.

Duncan

> On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts
> > Yes, against my better judgement the code in Cabal for haddock-2.x does
> > not run cpp or unliting like it does for haddock-0.x. Instead it assumes
> > that haddock-2.x will do all the cpp and unliting itself. Obviously this
> > mean the special unliting mode that Cabal provides is not usable with
> > haddock-2.x.
> >
> > The solution is to do the pre-processing the same for haddock-0.x and
> > 2.x. Generally the haddock code in Cabal is a horrible inconsistent
> > mess. I believe Andrea Vezzosi has been looking at rewriting it, which
> > is good news.