<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 19, 2010, at 4:33 PM, Kevin Horn wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">This time I think I'm gonna skip saying how I haven't gotten as much done as I would like...oh darn.<br><br>Anyways, time for another gripping installment...<br><br>Progress:<br>&nbsp; - tables are now handled (mostly) properly, thanks to Zeth at <a href="http://commandline.org.uk/">http://commandline.org.uk/</a><br>
&nbsp; - blockquote tags handled<br>&nbsp; - much improved whitespace/indentation handling<br>&nbsp; - some nicer styling thanks to Michael Thompson<br>&nbsp; - I've managed to convert the docs for the 3 Divmod projects with Lore <br>&nbsp;&nbsp;&nbsp; docs, though I've yet to put them up anywhere.<br></blockquote><div><br></div><div>Yay!</div><div><br></div><blockquote type="cite">&nbsp; - due to ReST's insistence on "inline markup" being surrounded by <br>&nbsp;&nbsp;&nbsp; whitespace or certain special characters, there are a lot of places where<br>&nbsp;&nbsp;&nbsp; such inline markup gets jacked up, by not including whitespace in front of <br>
&nbsp;&nbsp;&nbsp; it.&nbsp; If I put whitespace in front of everything though, my indentation <br>&nbsp;&nbsp;&nbsp; handling gets jacked up and about 400+ Sphinx build warning result.<br>&nbsp;&nbsp;&nbsp; Not sure if I should spend the time to make whitespace handling really <br>
&nbsp;&nbsp;&nbsp; smart or if these should just be fixed manually post-conversion.<br></blockquote><div><br></div><div>I don't really understand this problem. &nbsp;What do you mean about making whitespace handling really smart? &nbsp;Isn't this the sort of detail that docutils is supposed to handle for you?</div><br><blockquote type="cite">&nbsp; - Themeing/styling: still mostly a TODO, though new styling looks a lot <br>
&nbsp;&nbsp;&nbsp; better than the default to my eyes.&nbsp; I'm starting to think that <br>&nbsp;&nbsp;&nbsp; eventually we might want to have 2 themes/styles...one to match the <br>&nbsp;&nbsp;&nbsp; trac-based website, and one for bundled docs (docs tarballs, CHM files, etc.)<br></blockquote><div><br></div><div>That would certainly be nice, but is in no way required for the initial migration. &nbsp;Still, we should have a workable theme in order before we pull the trigger :).</div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font>&nbsp; - some of the Lore source files have nested "inline markup", which ReST <br>
&nbsp;&nbsp;&nbsp; disallows. &nbsp;<br></blockquote><div><br></div><div>Ugh. &nbsp;So ReST <b>can't do <i>this</i>?</b>&nbsp;&nbsp;That's pretty lame.</div><div><br></div><blockquote type="cite">&nbsp;&nbsp; &nbsp; &nbsp;- just handle the outside level of nesting (what I'm doing now) and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fix any problems manually post-conversion.<br></blockquote><div><br></div><div>I'm assuming there are very few instances of this, so that sounds fine.</div><br><blockquote type="cite">&nbsp; - xhtml entities are not currently resolved...mostly because it makes <br>&nbsp;&nbsp;&nbsp; the build take a LOOOONG time.&nbsp; They can be though.&nbsp; This shouldn't <br>&nbsp;&nbsp;&nbsp; be a problem.<br></blockquote><div><br></div><div>Are you resolving them by downloading all the DTDs or something?</div><br><blockquote type="cite">&nbsp;&nbsp;- Foolscap 0.5 was released today, which made me wonder what they use for</blockquote><blockquote type="cite">&nbsp;&nbsp;&nbsp; docs...and it's Lore.&nbsp; I brought this up on IRC, and it was suggested <br>
&nbsp;&nbsp;&nbsp; by many that Lore should stick around even after the conversion according <br>&nbsp;&nbsp;&nbsp; to the standard Twisted compatibility policy, to give anyone who still <br>&nbsp;&nbsp;&nbsp; uses it time to migrate.&nbsp; This sounds like a fine idea to me.&nbsp; <br>
&nbsp;&nbsp;&nbsp; Any thoughts?<br></blockquote><div><br></div><div>Since nobody really uses lore's API, the same compatibility policy doesn't really apply. &nbsp;In lore's case, I would say that the policy should be that we include it with X more releases just for packaging convenience, but stop doing maintenance immediately.</div></div><br></body></html>