I'm going to try and get this integrated. I'm not happy yet with the issue about blank lines vs '.' lines etc etc. I think that needs a wider discussion but I don't want to hold up what we already have. So I'll integrate it without the '.' line handling for now and we can discuss it further as necessary. Duncan On Thu, 2008-01-10 at 14:25 +0000, Alistair Bayley wrote:
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.