<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> - tables are now handled (mostly) properly, thanks to Zeth at <a href="http://commandline.org.uk/">http://commandline.org.uk/</a><br>
- blockquote tags handled<br> - much improved whitespace/indentation handling<br> - some nicer styling thanks to Michael Thompson<br> - I've managed to convert the docs for the 3 Divmod projects with Lore <br> docs, though I've yet to put them up anywhere.<br></blockquote><div><br></div><div>Yay!</div><div><br></div><blockquote type="cite"> - due to ReST's insistence on "inline markup" being surrounded by <br> whitespace or certain special characters, there are a lot of places where<br> such inline markup gets jacked up, by not including whitespace in front of <br>
it. If I put whitespace in front of everything though, my indentation <br> handling gets jacked up and about 400+ Sphinx build warning result.<br> Not sure if I should spend the time to make whitespace handling really <br>
smart or if these should just be fixed manually post-conversion.<br></blockquote><div><br></div><div>I don't really understand this problem. What do you mean about making whitespace handling really smart? Isn't this the sort of detail that docutils is supposed to handle for you?</div><br><blockquote type="cite"> - Themeing/styling: still mostly a TODO, though new styling looks a lot <br>
better than the default to my eyes. I'm starting to think that <br> eventually we might want to have 2 themes/styles...one to match the <br> 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. 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> - some of the Lore source files have nested "inline markup", which ReST <br>
disallows. <br></blockquote><div><br></div><div>Ugh. So ReST <b>can't do <i>this</i>?</b> That's pretty lame.</div><div><br></div><blockquote type="cite"> - just handle the outside level of nesting (what I'm doing now) and <br>
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"> - xhtml entities are not currently resolved...mostly because it makes <br> the build take a LOOOONG time. They can be though. This shouldn't <br> 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"> - Foolscap 0.5 was released today, which made me wonder what they use for</blockquote><blockquote type="cite"> docs...and it's Lore. I brought this up on IRC, and it was suggested <br>
by many that Lore should stick around even after the conversion according <br> to the standard Twisted compatibility policy, to give anyone who still <br> uses it time to migrate. This sounds like a fine idea to me. <br>
Any thoughts?<br></blockquote><div><br></div><div>Since nobody really uses lore's API, the same compatibility policy doesn't really apply. 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>