pagerender.rb: add footnote support, arch-systemd.md: use it.

I saw that the new version of rdiscount supported php-markdown-extra style
footnotes and got excited.  However, when I enabled it, I was disappointed
to learn that it didn't support multi-line footnotes. Lame!

So, I implemented that as a pre/post processor.

2 files changed, 52 insertions, 30 deletions

diff --git a/pagerender.rb b/pagerender.rb
index 021f66c..ecedaae 100755
--- a/pagerender.rb
+++ b/pagerender.rb
@@ -13,14 +13,29 @@ input = ARGV.first
 
 lines = File.read(input).split("\n")
 
+footnote_start = /^\[\^/
+footnote_cont = /^(\t| {2,4})/
+
 markdown = ''
 tags = {}
+footnotes = {}
+footnote_label = nil
 for line in lines do
 	if (line =~ /^:/)
 		(key, val) = line.sub(/^:/, '').split(/\s+/, 2)
 		tags[key] = val
 	else
-		markdown += "\n"+line
+		if (line =~ footnote_start)
+			footnote_label, footnote_body = line.split(':', 2)
+			footnote_label.gsub!(/[\^\[\]:]/, '')
+			footnotes[footnote_label] = footnote_body+"\n"
+			markdown += "[^#{footnote_label}]: 555PHONYFOOTNOTE555#{footnote_label}\n"
+		elsif (!footnote_label.nil? and line =~ footnote_cont)
+			footnotes[footnote_label] += line.sub(footnote_cont, '')+"\n"
+		else
+			footnote_label = nil
+			markdown += line+"\n"
+		end
 	end
 end
 
@@ -31,7 +46,12 @@ unless license_urls[@license].nil?
 	@license="<a href=\"#{license_urls[@license]}\">#{@license}</a>"
 end
 
-@content = RDiscount.new(markdown).to_html
+renderer = RDiscount.new(markdown)
+renderer.footnotes = true;
+@content = renderer.to_html
+footnotes.each do |label, body|
+	@content.gsub!("555PHONYFOOTNOTE555#{label}", RDiscount.new(body).to_html)
+end
 
 erb = ERB.new(File.read(template));
 erb.filename = template
diff --git a/public/arch-systemd.md b/public/arch-systemd.md
index c3b9b37..f0a484b 100644
--- a/public/arch-systemd.md
+++ b/public/arch-systemd.md
@@ -17,40 +17,42 @@ which just makes more sense.  It also means that a target can be
 started or stopped on the fly, such as mounting or unmounting a drive,
 which has in the past only been done at boot up and shut down.
 
-The **downside** is that it is (allegedly) big, bloated[[1](#foot1)], and does
-(arguably) more than it should.  Why is there a dedicated systemd-fsck?
-Why does systemd encapsulate the functionality of syslog? That, and it
-means somebody is standing on my lawn.
+The **downside** is that it is (allegedly) big, bloated[^1], and does
+(arguably) more than it should.  Why is there a dedicated
+systemd-fsck?  Why does systemd encapsulate the functionality of
+syslog? That, and it means somebody is standing on my lawn.
 
 The **changes** an Arch user needs to worry about is that everything
 is being moved out of `/etc/rc.conf`.  Arch users will still have the
 choice between systemd and SysV-init, but rc.conf is becoming the
 SysV-init configuration file, rather than the general system
 configuration file.  If you will still be using SysV-init, basically
-the only thing in rc.conf will be `DAEMONS`.[[2](#foot2)] For now
+the only thing in rc.conf will be `DAEMONS`.[^2] For now
 there is compatibility for the variables that used to be there, but
 that is going away.
 
-[<span id="foot1">1</span>]
-
-*I* don't think it's bloated, but that is the criticism.  Basically, I
-discount any argument that uses "bloated" without backing it up.  I
-was trying to say that it takes a lot of heat for being bloated, and
-that there is be some truth to that (the systemd-fsck and syslog
-comments), but that these claims are largely unsubstantiated, and more
-along the lines of "I would have done it differently".  Maybe your
-ideas are better, but you haven't written the code. 
-
-I personally don't have an opinion either way about SysV-init vs
-systemd. I recently migrated my boxes to systemd, but that was because
-the SysV init scripts for NFSv4 in Arch are problematic. I suppose
-this is another **advantage** I missed: *people generally consider
-systemd "units" to be more robust and easier to write than SysV
-"scripts".*
-
-I'm actually not a fan of either. If I had more time on my hands, I'd
-be running a `make`-based init system based on a research project IBM
-did a while ago. So I consider myself fairly objective.
-
-[<span id="foot2">2</span>] You can still have `USEDMRAID`, `USELVM`, `interface`, `address`,
-`netmask`, and `gateway`. But those are minor.
+[^1]:
+   *I* don't think it's bloated, but that is the criticism.
+   Basically, I discount any argument that uses "bloated" without
+   backing it up.  I was trying to say that it takes a lot of heat
+   for being bloated, and that there is be some truth to that (the
+   systemd-fsck and syslog comments), but that these claims are
+   largely unsubstantiated, and more along the lines of "I would have
+   done it differently".  Maybe your ideas are better, but you
+   haven't written the code.
+   
+   I personally don't have an opinion either way about SysV-init vs
+   systemd. I recently migrated my boxes to systemd, but that was
+   because the SysV init scripts for NFSv4 in Arch are problematic. I
+   suppose this is another **advantage** I missed: *people generally
+   consider systemd "units" to be more robust and easier to write
+   than SysV "scripts".*
+   
+   I'm actually not a fan of either. If I had more time on my hands,
+   I'd be running a `make`-based init system based on a research
+   project IBM did a while ago. So I consider myself fairly
+   objective.
+
+[^2]:
+   You can still have `USEDMRAID`, `USELVM`, `interface`, `address`,
+   `netmask`, and `gateway`. But those are minor.