Yes, choosing to use non-empty whitespace (to indicate that a comment block is not finished) might well be a poor design decision. Another possibility is to use a line containing a single period as a continuation line e.g.
I think we do this in Cabal descriptions (copying the design from Debian package's descriptions), so this would be consistent with that. It gets my vote!
I have implemented this, and made a couple of other changes: - use a single period on a line to indicate that we want to continue the comment block (like cabal does) - don't indent code relative to comments, because Haddock doesn't like this - reverse Left and Right cases in the Either returned by unlit, so that they're consistent with Either conventions (Left == failure, Right = success) - reclassify is simpler because there's no need for lookahead for the blank-followed-by-code case I've also updated the test module and the calling code in ppUnlit in PreProcess (because the Left and Right cases are reversed). I wanted to send a separate patch for each source file, but my darcs-fu is poor, and darcs insisted on including a bunch of older patches which are already in my repo and the main cabal repo. So it's all in one fat patch, which seems to include a bunch of older patches it depends on. I don't know why this is; I expected that "darcs pull" would have updated my repo w.r.t. the main cabal repo, so that this wouldn't be necessary. I'll try to get Haddock 2 soon and see how it fares with .lhs input. Alistair