]> sipb.mit.edu Git - ikiwiki.git/commitdiff
formatting
authorjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>
Thu, 12 Jul 2007 21:44:34 +0000 (21:44 +0000)
committerjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>
Thu, 12 Jul 2007 21:44:34 +0000 (21:44 +0000)
doc/patchqueue/calendar_--_archive_browsing_via_a_calendar_frontend.mdwn

index 9581ce40658cb3a170dbf81f830bd0b2b3eb0cdd..fe0dba1aaa7cca69e7896ca1cc8412035adf4c88 100644 (file)
@@ -593,16 +593,16 @@ I've been looking over the calendar plugin. Some items:
   that emitting the whole calendar in the preprocess hook would simplify
   things and you'd not need to save state about calendars.
 
-> A) I am scared of the html scrubber, and have never turned it on,
+> I am scared of the html scrubber, and have never turned it on,
 >        and did not look too deeply into what would be scrubbed out --ManojSrivastava
 >> Unless you're using javascript, a few annoyances link <blink>, or inline
 >> css, it's unlikly to object to any html you might write. The list of
 >> allowed tags and attributes is easy to find near the top of the plugin.
 
->     B) In case the option that gets the ctime of the pages from the
->        SCM itself, %IkiWiki::pagectime  is not populated that early,
->        is it? So I waited until the last possible moment to look at
->        the time information.
+> In case the option that gets the ctime of the pages from the
+> SCM itself, %IkiWiki::pagectime  is not populated that early,
+> is it? So I waited until the last possible moment to look at
+> the time information.
 >
 >> Actually, since my big rewrite of the rendering path a few months ago,
 >> ikiwiki scans and populates almost all page information before starting