patch applied (cabal): Fudge comment indentation in unliting to work with haddock

Sat Feb 2 20:23:08 PST 2008 Duncan Coutts

On Sat, Feb 02, 2008 at 08:28:35PM -0800, Duncan Coutts wrote:
Sat Feb 2 20:23:08 PST 2008 Duncan Coutts
* Fudge comment indentation in unliting to work with haddock The rule is, if we see any bird track style code then we will indent all comments by two spaces so that it should line up with the code. Otherwise we use no indentation so that it'll work with latex style literate files. This makes it work for takusen (once you change the '.' lines to be blank).
I haven't been following exactly what's been going on with this, but this sounds very wrong to me. Is this problem caused by using invisible spaces for comment continuation, or did using '.' have the same problem? Thanks Ian

On 04/02/2008, Ian Lynagh
On Sat, Feb 02, 2008 at 08:28:35PM -0800, Duncan Coutts wrote:
Sat Feb 2 20:23:08 PST 2008 Duncan Coutts
* Fudge comment indentation in unliting to work with haddock The rule is, if we see any bird track style code then we will indent all comments by two spaces so that it should line up with the code. Otherwise we use no indentation so that it'll work with latex style literate files. This makes it work for takusen (once you change the '.' lines to be blank). I haven't been following exactly what's been going on with this, but this sounds very wrong to me. Is this problem caused by using invisible spaces for comment continuation, or did using '.' have the same problem?
The problem is that Haddock expects comments to be indented to the same level as the code. If not then it gives a parse error. My solution was to not indent the birdtrack code, but Duncan pointed out that this is not consistent with the H98 spec, and also can break some code. So now we indent comments by two spaces instead. Obviously won't work for code that's indented with ">" rather than "> ", so you can't Haddock comment such code, but at least it won't break existing code. Alistair

On Mon, Feb 04, 2008 at 09:01:05PM +0000, Alistair Bayley wrote:
On 04/02/2008, Ian Lynagh
wrote: On Sat, Feb 02, 2008 at 08:28:35PM -0800, Duncan Coutts wrote:
Sat Feb 2 20:23:08 PST 2008 Duncan Coutts
* Fudge comment indentation in unliting to work with haddock The rule is, if we see any bird track style code then we will indent all comments by two spaces so that it should line up with the code. Otherwise we use no indentation so that it'll work with latex style literate files. This makes it work for takusen (once you change the '.' lines to be blank). I haven't been following exactly what's been going on with this, but this sounds very wrong to me. Is this problem caused by using invisible spaces for comment continuation, or did using '.' have the same problem?
The problem is that Haddock expects comments to be indented to the same level as the code.
Ah, I see. A more-correct thing to do might be to indent to the same depth as the next token? That would have the additional advantage of being able to document nested functions.
code. So now we indent comments by two spaces instead. Obviously won't work for code that's indented with ">" rather than "> ", so you can't Haddock comment such code
Not with literate comments, but you can if you use Haskell comments on birdtrack lines, presumably. In fact, I hadn't appreciated that non-Haskell comments would end up being picked up by haddock. Thanks Ian

On Mon, 2008-02-04 at 21:37 +0000, Ian Lynagh wrote:
Ah, I see.
A more-correct thing to do might be to indent to the same depth as the next token? That would have the additional advantage of being able to document nested functions.
True. I'm happy to see a patch like that. One way to do it might be to groupBy the line kind. By walking over those blocks you'd might have enough lookahead to see what the indent level should be.
code. So now we indent comments by two spaces instead. Obviously won't work for code that's indented with ">" rather than "> ", so you can't Haddock comment such code
Not with literate comments, but you can if you use Haskell comments on birdtrack lines, presumably.
Sure, that's always worked because it gets unlited.
In fact, I hadn't appreciated that non-Haskell comments would end up being picked up by haddock.
That's what this whole thing is about, allowing haddock markup in the comment sections of .lhs files. eg: http://darcs.haskell.org/takusen/Database/Enumerator.lhs Duncan

That's what this whole thing is about, allowing haddock markup in the comment sections of .lhs files. eg: http://darcs.haskell.org/takusen/Database/Enumerator.lhs
I've (finally) tested this with Takusen source and it seems to work well. Any further testing you'd like me to try? Alistair

On Tue, 2008-02-12 at 08:47 +0000, Alistair Bayley wrote:
That's what this whole thing is about, allowing haddock markup in the comment sections of .lhs files. eg: http://darcs.haskell.org/takusen/Database/Enumerator.lhs
I've (finally) tested this with Takusen source and it seems to work well.
Great.
Any further testing you'd like me to try?
I'm happy as it is. If we want more there's Ian's suggestion about doing a slightly more sophisticated indenting pass. Duncan
participants (3)
-
Alistair Bayley
-
Duncan Coutts
-
Ian Lynagh