<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
> But that's unwanted, as those backslashes show up in GHC(i) messages.<br>
> So: how do I get haddock to not parse my '<^>' operator as a link/URL?<br>
<br>
</div>Hm, strange, technically we parse identifiers first and links second so<br>
this should work without a problem unless Haddock doesn't recognise it<br>
as an identifier.<br>
<br>
I actually now notice in the parser that we don't consider ^ to be a<br>
valid symbol so that's probably the culprit! Good catch, if that's<br>
actually the case here then you can expect it to be fixed in the next<br>
release, perhaps with 7.8.3 or something. Unfortunately the way we do<br>
identifier parsing now is that we slurp everything that looks like a<br>
valid identifier and afterwards we ask GHC to actually tell us if it's<br>
it's something we know about. It seems like a bug caused by me not being<br>
careful when reading the relevant part of the report, deepest apologies!<br>
I do wish we had a better way of parsing these identifiers but I can't<br>
think of one.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>It never came to mind that '^' was the actual culprit :-)</div><div>Now that I know that it's a (potential) bug, I'll just keep my eye on ghc-commit and wait for the bugfix.</div>
<div>I'm used to running ghc-HEAD anyway.</div><div><br></div><div>Also, is it not possible to update my haddock seperate from GHC?</div><div><br></div><div>-- Christiaan</div></div><br></div></div>