<div class="gmail_quote">On Wed, Jan 20, 2010 at 9:57 PM, Glyph Lefkowitz <span dir="ltr"><<a href="mailto:glyph@twistedmatrix.com">glyph@twistedmatrix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="word-wrap: break-word;"><div><div class="im"><div>On Jan 19, 2010, at 4:33 PM, Kevin Horn wrote:</div><br><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/" target="_blank">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><div>Yay!</div><div class="im"><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><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>
<div class="im"><br></div></div></div></blockquote><div><br>OK, lemme esplain...no, would take too long, lemme sum up.<br><br>In some of the Lore docs, you have stuff like:<br><br> some<em>stuff</em><br><br>
which naively translated to ReST looks like:<br><br> some*stuff*<br><br>but since ReST wants whitespace and/or special characters surrounding "inline markup", docutils/Sphinx doesn't recognize it properly as markup and just sends it unmodified to the HTML (or whatever) output..<br>
<br>The obvious solution is to just surround all inline markup with spaces, since we're mainly targeting HTML output at the moment and a few extra spaces shouldn't hurt. Which would look like this:<br><br> some *stuff*<br>
<br>But this turns out to cause other problems, specifically in the case where inline markup occurs on the beginning of a line, and the extra space jacks up the indentation (which ReST considers significant).<br><br>So the whitespace handling I was referring to was the output of whitespace from lore2sphinx.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><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><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></div></div></blockquote>
<div><br>Right, as I said "eventually".<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;">
<div><div class="im"><blockquote type="cite"><font color="#000000"><br></font> - some of the Lore source files have nested "inline markup", which ReST <br>
disallows. <br></blockquote><div><br></div></div><div>Ugh. So ReST <b>can't do <i>this</i>?</b> That's pretty lame.</div></div></div></blockquote><div><br>It's a little bit lame, but I've found that it doesn't occur all that often in practice. Every markup language has it's limitations, and this is one I can live with.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><div></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><div>I'm assuming there are very few instances of this, so that sounds fine.</div></div></div></blockquote><div><br>That's pretty much my plan.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><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><div>Are you resolving them by downloading all the DTDs or something?</div>
</div></div></blockquote><div><br>The lxml parser can download DTDs in order to resolve external entities, but the way things are currently set up, it would end up doing this once for each Lore source file, which ends up making my build process take much longer. Because I didn't want to deal with this during development, and since there are only like 4 external entities in all of the Lore docs, I turned this off and told lxml to ignore the errors. It may be that there is a better way to do this (maybe cache the DTDs somehow), but I haven't really bothered with it yet. It's a simple matter to turn it back on when we're ready, even if there isn't an easy/convenient way to avoid the repeated downloads of the DTDs.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><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><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></div><br></blockquote></div><br>Fine with me.<br><br>Kevin Horn<br>