From 8aa76ebdabbe6d65d1d520948b3e4ad598f46003 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Sun, 13 Oct 2013 14:11:12 -0400 Subject: 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. --- pagerender.rb | 24 +++++++++++++++++++-- public/arch-systemd.md | 58 ++++++++++++++++++++++++++------------------------ 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="#{@license}" 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. -[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. +[^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. -- cgit v1.2.3