Haddock/hscolour integration broken on Hackage?

I was looking at the Data.Binary documentation[1] on Hackage, and I've noticed some problems with the associated source listings[2]. First, none of the "Source" links work. They all refer to fragment IDs (e.g., "#Binary") that are not defined. I'm not sure if this is a problem with hscolor, haddock, or hackage. Second, the source listing itself[2] is invalid HTML[3]. The W3C validator lists 678 errors. Of these, 677 are have to do with the line number anchors, all of which start with parentheses. This is bad not only because HTML requires fragment ids to start with a letter, but because parentheses are not allowed to occur in URIs. As a result, links to line numbers will come out looking like "Data-Binary.html#%28line100%29". [1] http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary.... [2] http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/src/Data-Bin... [3] http://validator.w3.org/check?uri=http%3A%2F%2Fhackage.haskell.org%2Fpackages%2Farchive%2Fbinary%2F0.3%2Fdoc%2Fhtml%2Fsrc%2FData-Binary.html&charset=%28detect+automatically%29&doctype=Inline&group=1

On Mon, 2007-09-10 at 14:11 -0400, David Menendez wrote:
I was looking at the Data.Binary documentation[1] on Hackage, and I've noticed some problems with the associated source listings[2].
First, none of the "Source" links work. They all refer to fragment IDs (e.g., "#Binary") that are not defined. I'm not sure if this is a problem with hscolor, haddock, or hackage.
Second, the source listing itself[2] is invalid HTML[3]. The W3C validator lists 678 errors. Of these, 677 are have to do with the line number anchors, all of which start with parentheses. This is bad not only because HTML requires fragment ids to start with a letter, but because parentheses are not allowed to occur in URIs. As a result, links to line numbers will come out looking like "Data-Binary.html#%28line100%29".
[1] http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary.... [2] http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/src/Data-Bin... [3] http://validator.w3.org/check?uri=http%3A%2F%2Fhackage.haskell.org%2Fpackages%2Farchive%2Fbinary%2F0.3%2Fdoc%2Fhtml%2Fsrc%2FData-Binary.html&charset=%28detect+automatically%29&doctype=Inline&group=1 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
This might be related to the error message in the build log [1] Warning: Data.Binary: the following names could not be resolved: v which comes from the example in the description of the 'Binary' class. I think the problem is the use of 'v' instead of @v@. Interestingly, it works for the other modules like Data.Binary.Put and .Get [1] .. http://hackage.haskell.org/packages/archive/binary/0.3/log

"David Menendez"
I was looking at the Data.Binary documentation[1] on Hackage, and I've noticed some problems with the associated source listings[2].
First, none of the "Source" links work. They all refer to fragment IDs (e.g., "#Binary") that are not defined. I'm not sure if this is a problem with hscolor, haddock, or hackage.
Some of the source links do work, e.g. #encodeFile. I believe those that do not work are due to a documented limitation of hscolour, that it is unable to lexically discover class methods, in order to place an anchor in front of them.
Second, the source listing itself[2] is invalid HTML[3]. The W3C validator lists 678 errors. Of these, 677 are have to do with the line number anchors, all of which start with parentheses.
Oops. The line number anchors were added to hscolour in a patch
contributed by a third party, which I accepted in good faith. Since I
have no need of line number anchors myself, maybe the easiest solution
is simply to rollback that patch for the next version of hscolour.
If someone wants to do this for their own copy of hscolour, the patch in
question is this one:
Sat Apr 21 01:27:56 BST 2007 Roberto Zunino

Malcolm Wallace wrote:
"David Menendez"
writes: I was looking at the Data.Binary documentation[1] on Hackage, and I've noticed some problems with the associated source listings[2].
First, none of the "Source" links work. They all refer to fragment IDs (e.g., "#Binary") that are not defined. I'm not sure if this is a problem with hscolor, haddock, or hackage.
I suspect this is because current cabal does not use %LINE links, as I did in my original patch. See for discussion http://article.gmane.org/gmane.comp.lang.haskell.cabal.devel/727/match=haddo... Unfortunately %LINE is not yet widely available (only in darcs Haddock).
Some of the source links do work, e.g. #encodeFile. I believe those that do not work are due to a documented limitation of hscolour, that it is unable to lexically discover class methods, in order to place an anchor in front of them.
%LINE would sidestep this issue.
Second, the source listing itself[2] is invalid HTML[3]. The W3C validator lists 678 errors. Of these, 677 are have to do with the line number anchors, all of which start with parentheses.
Oops. The line number anchors were added to hscolour in a patch contributed by a third party, which I accepted in good faith.
That's me, I am sorry for that. I chose "(line" and a prefix for the anchors because no otherwise-generated anchor by HsColour can cause a conflict with it. I see now that was indeed a poor choice. Would be enough to use the %xx encoding of parenthesis? Would you instead use another prefix (it is enough that no haskell identifier can start with it)? Maybe ".line" or "-line" ? If you want me to send a patch for that, I will. And I'll run the HTML validator this time.
Since I have no need of line number anchors myself, maybe the easiest solution is simply to rollback that patch for the next version of hscolour.
Wrt removing line anchors, I still think that %LINE is the right way to go (well, either that or including a full-featured parser in HsColour). But, of course, the maintainer has the last word about it! :-) Regards, Zun.

Roberto Zunino wrote:
Would be enough to use the %xx encoding of parenthesis? Would you instead use another prefix (it is enough that no haskell identifier can start with it)? Maybe ".line" or "-line" ?
AFAICS, I think "line-" should do. From w3.org: ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). Zun.
participants (4)
-
David Menendez
-
Malcolm Wallace
-
Roberto Zunino
-
Thomas Schilling