<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I don&#39;t think that the present location of XConfig is a barrier to a
<br>good haddock documentation. Do I miss something?<br></blockquote><div><br>Not technically, except that if XConfig is in Core.hs, the haddock documentation for XConfig will be buried at the end of a very long haddock page for 
Core.hs.&nbsp; The general idea was to separate documentation for things that the casual user (doesn&#39;t know much Haskell but thinks xmonad is cool and just wants to get xmonad working as easily as possible) cares about, such as XConfig, from things that the power user (knows Haskell and wants to contribute their own extension modules, etc.) cares about, such as Core.&nbsp; In general, I strongly believe that the presentation of information is just as important as the actual content.
<br></div><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(btw, I documented each record field of XConfig in a patch that has<br>
been committed yesterday, and I&#39;ve just discovered that the darcs<br>version of haddock[1] properly deals with newtype deriving, which<br>means that everyone may be generating the haddock documentation.)<br></blockquote>
<div><br>oh, excellent, I didn&#39;t see that yet.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Did you see the work I&#39;m doing with documenting all this stuff[2]?
<br></blockquote><div><br>I did!&nbsp; I think it&#39;s great.&nbsp; And I assume you saw the e-mail I just sent with my thoughts on the matter.<br><br>-Brent</div></div>