On Thu, Feb 21, 2008 at 5:37 PM, Duncan Coutts &lt;<a href="mailto:duncan.coutts@worc.ox.ac.uk">duncan.coutts@worc.ox.ac.uk</a>&gt; wrote:<br>
<br>
&gt; So the advantage of passing the rest through uninterpreted is that<br>
&gt; markdown then interprets it and we get lots of cool markup for free, the<br>
&gt; disadvantage is that we get lots more markup that I don&#39;t<br>
&gt; understand! :-)<br>
<br>
Thanks for this summary, Duncan.<br>
<br>
&gt; There really is something to be said for being able to download a random<br>
&gt; package, read the code at the documentation markup and be able to<br>
&gt; understand it and modify it. If it&#39;s a simple common language like we<br>
&gt; have at the moment we can do that. I worry about loosing that property.<br>
<br>
Have you looked at markdown?&nbsp; It&#39;s a popular and well-documented format
and based on common conventions.&nbsp; I bet you&#39;d have no trouble learning
it, and I bet many other Haskell programmers *already* know it.&nbsp; (BTW,
I just noticed that this mail message is in written in markdown.)<br>
<br>
&gt; So yes we could make haddock not care so much and pass everything<br>
&gt; through and then people could do whatever they liked with new markup<br>
&gt; formats but I wonder if we cannot find a common language that we can all<br>
&gt; agree on. Are there any particularly cool things in markdown that lots<br>
&gt; of haskell developers want to use in their api documentation?<br>
<br>
My previous note listed some (pandoc-extended) markdown features I use
regularly (while blogging) that are missing in Haddock.&nbsp; If I could,
I&#39;d use them in my code documentation.<br>
<br>
I&#39;d like to hear from others about what markup features you&#39;d like to
have in your code documentation but aren&#39;t supported by Haddock.<br>
<br>
Cheers,&nbsp; - Conal<br>
<br>