nandoc 0.0.1

data/README

@@ -0,0 +1,124 @@
+<embed
+  style='position: absolute; right:0; top:0'
+  src="svg/less-fonts.svg" width="150px" height="150px"
+  type="image/svg+xml"
+  pluginspage="http://www.adobe.com/svg/viewer/install/" />
+
+# NanDoc
+this is a hack. this is nanDoc.
+
+## Summary
+
+hack of [nanoc3](http://nanoc.stoneship.org) to generate a static site of your ruby project from your README etc.
+
+## Description
+
+Generate a static site to document your ruby project from your README and other markdown-formatted documentation.  Inject code examples from your unit tests into the generated docs.  Extremely fragile hacks and some cool additions to nanoc3.
+
+(This entire site is generated from a README and other docs with all
+of the code examples coming from unit test "scrapes.")
+
+## Does this match you?
+
+* Tired of all the other unit-test-driven static documentation-site-generators
+that fall short of the usual promises?
+
+* Agile development has your documentation content going rapidly stale?
+
+* Sick of typing what you want to write by hand?
+
+* Repeatedly hearing yourself repeat to yourself "Don't Repeat Yourself?"
+
+* Don't underkill your documentation when it's so easy to &Uuml;berkill&trade; it!  Don't be fooled by impostors!
+
+<b>IF</b> you ansewered <b>YES</b> to zero or more of the above questions (of those that were
+questions and not imperative statements), then <b>DON'T WAIT!</b>   Press that
+big giant silver spherical DWIM button floating in the sky!
+
+
+## High Concept
+A semi-attractive RIA sopping with Web 1.0 gooey-goodness is just a view on your existing
+vanilla documentation that you've surely been writing all along.
+
+Nanoc3 makes making web sites fun and easy.  Markdown makes documenting your projects fun and easy.  Now, NanDoc puts the two together to make making web sites that present your markdown-documented projects tons of fun and super easy.
+
+The crackiest part about it is when you start writing unit tests that provide example code for your docs.  I really need to document this, both to document it and to showcase it.  It's really important for humanity.  It's tantamount to learning how to sing with your fingers.  Or putting a webcam in your shower, depending on how good you are at writing tests, or how good your shower looks.
+
+## Installation
+
+If we are lucky something like this will work:
+    from the command line:
+    ~~~
+    ~ > gem install -n ~/bin nandoc
+    ~~~
+
+<em>(that <code>-n ~/bin</code> thing is just a matter of preference)</em>
+
+<br />
+
+To hack, try something like this:
+    from the command line:
+    ~~~
+    ~/tmp > git clone git@github.com:hipe/nandoc.git
+    ~/tmp > cd nandoc
+    ~/tmp/nandoc > rake gem
+    ~/tmp/nandoc > gem install -n ~/bin pkg/nandoc-0.0.0.gem
+    ~~~
+
+
+## Usage Summary
+
+Start with  a markdown-formatted README file:
+
+(see: test.rb - "basic usage -- readme")
+
+<br />
+
+Then, next to this readme create a nanoc3 site/project with
+nanDoc&reg;-powered&trade; nanoc&copy;:
+
+(see: test.rb - 'basic usage -- create site')
+
+<br />
+
+Finally, compile your site with the nanoc3 `compile` command:
+
+(see: test.rb - 'basic usage -- create site' - 'compile site')
+
+<br />
+
+From the command line start the nanoc3 (`adsf`) server:
+    from the command line:
+    ~~~
+    ~/tmp/my-site >nandoc view
+    ~/tmp/my-site >
+    ~~~
+
+<br />
+
+If all the bells are polished and whistles tuned, you will have a
+site as handsome, usable as self-unawarely-understatedly brilliant as this
+one, but stunningly and proudly your own:
+
+(point and aim your browsing device to `http://localhost:3000/`)
+
+<div style='border: 1px solid gray; width: 800px; padding: 0 0 1em 0;'>
+  (see: test.rb - 'basic usage -- create site' - 'index page body')
+  <div class='clear'>&nbsp;</div>
+</div>
+
+<br/>
+
+This entire readme file/site showcases much of the currently exisiting site generation haxies available in the nanDoc hacks of nanoc3; and the example code and output you see above is generated from the unit tests in this project. [^treebis]
+
+Even the above example page is generated by a README in a unit test and injected into this page (which itself is generated from the README of this project.)
+
+Customizing your site is a matter of getting to know nanoc3 and discovering all the fantastic undocumented features hiding in nanDoc. (My next steps are to use this fun new tool to actually document how to use it to generate )
+
+NanDoc. Genius never looked so stupid&reg;.
+
+<br />
+<hr />
+<span style='font-size: 0.85em'>appologies to william morgan's [trollop](http://trollop.rubyforge.org/) site, product, and person for unwittingly encouraging me, and providing the CSS styles for the highlighted ruby code.</span>
+
+[^treebis]:checkout the [treebis](http://treebis.hipeland.org) code to see some 'specdoc' features not used here.

data/Rakefile

@@ -0,0 +1,53 @@
+require File.expand_path('../lib/nandoc/parse-readme.rb', __FILE__)
+
+task :default => :test
+
+me = "\e[35mnandoc\e[0m "
+
+require 'jeweler'
+Jeweler::Tasks.new do |s|
+  s.authors = ['Chip Malice']
+  s.description = NanDoc::ParseReadme.description('README')
+  s.email = 'chip.malice@gmail.com'
+  s.executables = ['nandoc']
+  s.files =  FileList['Rakefile', '[A-Z]*(?:\.md)?', '{bin,doc,lib,test,proto}/**/*']
+  s.homepage = 'http://nandoc.hipeland.org'
+  s.name = 'nandoc'
+  s.rubyforge_project = 'nandoc'
+  s.summary = NanDoc::ParseReadme.summary('README')
+
+  s.add_dependency 'nanoc3', '~> 3.1.2'
+  s.add_dependency 'treebis', '~> 0.0.1'
+  s.add_dependency 'syntax', '~> 1.0.0'
+end
+
+
+desc "#{me}hack turns the installed gem into a symlink to this directory"
+task :hack do
+  kill_path = %x{gem which nandoc}
+  kill_path = File.dirname(File.dirname(kill_path))
+  new_name  = File.dirname(kill_path)+'/ok-to-erase-'+File.basename(kill_path)
+  FileUtils.mv(kill_path, new_name, :verbose => 1)
+  this_path = File.dirname(__FILE__)
+  FileUtils.ln_s(this_path, kill_path, :verbose => 1)
+end
+
+desc "#{me}generate rcov coverage"
+task :rcov do
+  sh %!rcov --exclude '.*gem.*' test/test.rb -- --seed 0!
+end
+
+desc "#{me}run the test file"
+task :test do
+  sh %!ruby -w -e 'require "test/test.rb"'!
+end
+
+# desc "#{me}remove temporary, generated files like coverage"
+# task :prune do
+#   require File.dirname(__FILE__)+'/lib/nandoc.rb'
+#   file_utils = NanDoc::Config.file_utils
+#   these = ['./lib/nandoc/treebis/coverage']
+#   these.each do |this|
+#     file_utils.remove_entry_secure(this, :verbose=>true)
+#   end
+# end

data/bin/nandoc

@@ -0,0 +1,6 @@
+#!/usr/bin/env ruby
+$LOAD_PATH.unshift(File.expand_path('../../lib', __FILE__))
+
+require 'nandoc'
+
+Nanoc3::CLI::Base.shared_base.run(ARGV)

data/doc/CREDITS.md

@@ -0,0 +1,6 @@
+# NanDoc
+
+## Credits
+
+  * of course Denis Defreyne for [nanoc3](http://nanoc.stoneship.org/)
+  * William Morgan ([trollop](http://trollop.rubyforge.org/)), whose no-nonsense site inspired the design of the nanDoc default prototype site (in fact the whole project), and whose mostly unaltered stylesheet is used for the default ruby syntax colorization.

data/doc/FAQ/why-not-wiki.md

@@ -0,0 +1,20 @@
+# Q: Why not a wiki or a CMS?
+<p class='answer'>A: I don't have any experience running a wiki, and only a little experience hacking on them (a lot if you count radiant cms).  With that stated:</p>
+
+(I was going to make this a PRO's and CON's list but whether the below points are a pro or a con depends on your specific requirements[^assess].)
+
+  * wikis are more publicly editable.  With the nanDoc, people would have to submit edits to docs patches and/or fork.
+
+  * some wikis require dedicated server software.  NanDoc uses nanoc3 to generate a static site that you can serve with any http server that serves html documents.
+
+  * a given wiki supports a subset of the large variety of markup languages available [^markups].  Out of the box nandoc uses kramdown (markdown), but in theory can be configured to support any of the filters that nanoc3 can support.  Out of the box nanDoc uses markdown because it seems to be a de-facto standard for this kind of thing (at least to the extend that github supports "Github Flavored Markdown").  Out of the box nanDoc uses kramdown to parse markdown because it is clean and hackable, and performance isn't important.
+
+  * github and the like usually give you a wiki for your project.  I don't know to what extent you can get a handle on the content files for this wiki, and have them versioned, etc.
+
+  * I spent a good amount of time making that auto-generated site-map left nav thing, and the auto-generated top-nav bread-crumber thing (which are optional).  In my experience with writing wiki pages this was always an annoyance, dealing with the information architecture of your site.  (In most wikis it seems like a page doesn't really exist unless you link to it, and out of the box most wiki's don't seem to present to you a hierarchical tree of nodes, but rather a flat list of documents that can be linked to; or more accurately don't exist until they are linked to.)
+
+  * More generally the thing about nanDoc is that it can allow you to couple tightly your code and your docs, so for example if someone is watching your project on github they will get notified all the same when either your code or or you docs are updated.
+
+
+[^assess]: coming soon!
+[^markups]: @todo make a nice comparison matrix of these somewheres.

data/doc/FAQ.md

@@ -0,0 +1,68 @@
+# Frequently Asked Questions
+<span style='font-size: 0.9em'><em>I can't walk 2 blocks outside my home without some stranger coming up to me and asking me one or more of these questions.</em></span>
+
+## Q: Why not jekyll?
+<p class='answer'>A: I started this knowing nothing about jekyll.  nanoc3 found me and i was already acquainted with its author and i liked what i saw so i just ran with it without doing a broad survey of other solutions.  At the time of this writing i still don't really know jekyll. @todo</p>
+
+## Q: What about a wiki or a CMS?
+<p class='answer'>A: Yeah that's sorta what this feels like, isn't it.  I don't know!  What about it?  Musings <a href='why-not-wiki/'>here</a>.</p>
+
+## Q: Why do you keep calling nanDoc a hack?
+<p class='answer'>A: nanoc3 although awesome didn't meet the first requirement of nanDoc which was to use as source content a README (and other assets) that live at the root of your project (e.g. gem); as opposed to living in <code>my-site/content</code> folder the way nanoc3 wants it.  Nanoc3 wants it this way for good reason, as it turns out, because it takes some work to deal with pulling content from arbitrary folders and files; and to bend Nanoc3 to do this has resulted in a fragile rube-goldberg machine.
+</p>
+
+(It bears mentioning that those parts of nanDoc not concerned with the above are not as fragile and quite awesome.)
+
+## Q: Why the hell do you want to do it this way? Why so many hoops?
+<p class='answer'>A: Because I hate hate hate it when my documentation can't keep up with the way my code works, or worse lies about it; and I love love love the idea of generating as much as possible good documentation from good tests.</p>
+
+I heard that with BSD/GNU/unix tools you couldn't release an alpha version of the thing without first finishing your manpage [citation needed].  In many responsible shops you can't commit your code unless it's covered by tests and doesn't break the other tests.  With nanDoc you can't build your documentation unless your (relevant) tests pass, and it's not easy to build good documentation without them.  I like it this way.  If you don't, read these nikes!
+
+## Q: But what about rdoc/yard?
+<span class='answer'>A:</span> Rdoc/yard are important tools that do what they do well. [^notyet] NanDoc is certainly not a replacement for them.
+
+Rdoc/yard are good at generating API documentation and that's what they should be used for.  NanDoc is for creating a narrative story, (indeed a grand metanarrative in the spirit of Lyotard,[^lyotard]) with a beginning middle and end (and hopefully some pretty pictures along the way); and grabbing pieces from your tests to use as examples (illustrations) in the story; or possibly creating taxonomies of such narratives.[^yard]
+
+## Q: What about (python's) doctest?
+<p class='answer'>A: Python's doctest seems nifty and was one of the inspirations for this.  However the overriding convention of the day seems to be to let your tests ("specs") live in their own files; and I like it this way so that when I'm looking at code I can read code and not let it get cluttered by natural language explaining (or possibly lying about) what the code <em>should</em> do.</p>
+
+Whereas doctest is about writing comments that have embedded code that makes a test that tells a story, nanDoc is about taking your tests that tell a story and injecting parts of them into your (narrative) documentation.
+
+Recent-esque trends in some parts (behavior-driven development, user-stories, cucumber et-al) have fed into the inpiration for this; but they don't run all the way to the finish line which is to give an accessible, natural language context to their stories beyond what code is capable of or should be used for.
+
+## Q: Could this idea behind nanDoc somehow be extended further with unit testing frameworks that bend themselves around telling a story?
+<span class='answer'>A:</span> Yes. [^cucumber][^dtdsl]
+
+
+## Q: Will NanDoc be useful for generating docs for my Rails app or my Restful API, or my Ruby library?
+<p class='answer'>A: No, as it is I don't really think so.  For now it seems to be focused on writing narratives to explain command-line apps.  I need to think about this!  (hrm oops drats.)
+</p>
+
+Wait, come to think of it, yes maybe.  If generating a static website from markdown-formatted files that live in arbitrary locations in your project is exactly what you have in mind, then nanDoc is your new best friend.
+
+
+## Q: But what about LaTeX?
+<p class='answer'>A: If you know what LaTeX is you should put this book down right now and continue writing your own! (I'm lookin' at you, Ramaze!) (heh or not it has its disadvantages n'est-ce pas?) I like markdown-esque syntax because it's human readable as a plain-text document and it gets "this" job done.  But of course it can't do everything.  If you were to try and write a nanoc3 filter that reads TeX and outputs html/css/assets then you my friend are hereby being called a black pot by one crazy kettle.</p>
+
+This is me trying not to think about generating a pdf from a nanDoc-generated site.  (I guess the first question would be, "why?").
+
+Also kramdown (that nanDoc uses) apperantly already supports LaTeX [math blocks](http://kramdown.rubyforge.org/syntax.html#math-blocks) which (like the safety cushion in an aiplane that can also be used as a flotation device) I don't ever plan on using but am glad exist.
+
+<br />
+<br />
+<br />
+<hr />
+## Die Fußnoten
+
+[^notyet]:  At least, I think rdoc and yard are important tools. I haven't really gotten to know them yet at the time of this writing.  (I do know yard's author to be sharp, however.)
+
+[^yard]: Up next and pretty soon here, i'm going to look into generating sister taxonomies from the api docs generated by yard and having them live next to the web content generated by markdown files.  (Nokogiri's and the prettier but now hard to find site for Hpricot are good examples of this.)  (Hpricot's now defunct site was a big inspiration for this.  Just perfect.)
+
+
+[^lyotard]: Ok actually he probably would [not](http://en.wikipedia.org/wiki/Metanarrative#Replacing_grand.2C_universal_narratives_with_small.2C_local_narratives) write one, would that poststructuralists wrote software, which is to say that they don['](http://rubyconf2007.confreaks.com/d1t1p1_what_makes_code_beautiful.html)t.
+
+
+[^cucumber]: The first time I tried using cucumber it annoyed me the way rspec annoys people who are used to vanilla Test::Unit tests.  But potential seems to be there (and has been surely been explored to a fuller extend elswhere [citation needed]) to do something like generating docs from these kind of tests.
+
+
+[^dtdsl]: Or you might be like Dave Thomas (whoever he is) and [hate all DSL's](http://pragdave.blogs.pragprog.com/pragdave/2008/03/the-language-in.html)

data/doc/TODOs-and-BUGs.md

@@ -0,0 +1,15 @@
+# Todo's and Bugs
+_(rougly in order of priority)_
+
+## Todo's
+* document DocSpec and MockPrompt!!
+* document the tags in the filter (satisfied partly by below & above)
+* integrate yard api doc generation
+* add explicit dependency on minitest (or not)
+* document diffing commands
+
+## Bugs
+* live [here](http://github.com/hipe/nandoc/issues)
+
+## Wishlist
+* partial compile of only certain pages? ick.

data/doc/bar/baz.md

@@ -0,0 +1,4 @@
+# what a crazy
+
+## way to
+write your docs

data/doc/bar/bliff.md

@@ -0,0 +1,8 @@
+# what if
+
+## you wrote
+
+all your documenation
+~~~
+like this
+~~~~

data/doc/foo.md

@@ -0,0 +1,5 @@
+i am some secret content
+### in this
+strange file
+
+see bar somehow

data/doc/getting-started.rb

@@ -0,0 +1,13 @@
+### requirements
+
+boobric foobric blaz
+~~~
+some code
+~~~
+
+
+blaff bliff bloof
+
+#### other stuff
+
+that's how you just got started

data/doc/svg/less-fonts.svg

@@ -0,0 +1,21 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by hipe version 0.0.0 (20100126.1600)
+ -->
+<svg width="175" height="175"
+ viewBox="0.00 0.00 175.00 175.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="blah1" class="whatevs" transform="scale(1 1) rotate(0) translate(0 0)">
+<title>this_some_awesome_thing</title>
+<polygon fill="white" stroke="white" points="5,140 5,0 140,0 140,140 5,140"/>
+<g id="node1" class="node"><title>song</title>
+<polygon fill="#ff3300" points="19,0 175,0 175,132 169,122 162,132 157,122 148,130 145,119 136,127 133,116 124,124 121,113 112,120 109,109 99,116 98,104 87,109 87,98 76,104 76,92 65,97 65,86 54,91 55,80 43,84 45,73 33,75 38,64 26,64 32,54 21,53 28,44 17,42 25,34 14,32 23,25 12,21 22,16 12,12 21,7 13,3 15,0"/>
+
+<g id="blah2" class="whatevs" transform="scale(1) rotate(20) translate(12, -30)">
+<text text-anchor="middle" x="108" y="32" font-family="Super Sans; sans-serif" font-size="25" fill="#ffffff">now with</text>
+<text text-anchor="middle" x="108" y="59" font-family="serif" font-size="25" fill="#ffffff">less fonts!</text>
+</g>
+
+</g>
+</g>
+</svg>

data/lib/nandoc/commands/create-nandoc-site.rb

@@ -0,0 +1,225 @@
+module NanDoc
+  class CreateNanDocSite < ::Nanoc3::CLI::Commands::CreateSite
+    #
+    # Most of this is fluff/filler/hacks.  The key is that 1)
+    # in run() we set the datasource to be NanDoc::DataSource and 2)
+    # after the parent's site_populate() is run we apply our patch to it.
+    #
+
+
+    include OptsNormalizer, TaskCommon, CliCommandHelpers
+
+    def name; 'create_nandoc_site' end
+
+    def aliases; [ 'cnds', 'cns', 'cs' ] end # override create_site short!
+
+    def short_desc; 'create a nandoc site' end
+
+    def long_desc
+      <<-D.gsub(/\n +/,' ')
+      (nanDoc hack) Create a new site at the given path. This builds on the
+      create_site nanoc3 command.  Please see that for more
+      information.  Run this next to your README.md file.
+      D
+    end
+
+    def usage; "nandoc create_nandoc_site [-m] <path>" end
+
+    def option_definitions
+      [
+        { :long => 'patch-hack', :short => 'p', :argument => :none,
+          :desc => '(nanDoc hack) use files not patches when necessary' },
+
+        { :long => 'merge-hack', :short => 'm', :argument => :none,
+          :desc =>
+            '(nanDoc hack) when site already exists do something clever'
+        },
+        { :long => 'merge-hack-reverse', :short => 'M', :argument => :none,
+          :desc =>
+            '(nanDoc hack) show the reverse diff of above.'
+        }
+      ]
+    end
+
+    #
+    # On the _merge option: when we are doing a merge with a generated
+    # site and we want to generate a fresh site, we want to turn the below
+    # stderr hack off.
+    #
+    def run(opts, args, method_opts={:_merge=>true})
+      opts = normalize_opts opts
+      run_opts_process opts
+      #
+      # awful: see if nanoc triggers the error message about site
+      # already existing, then take action
+      #
+      if method_opts[:_merge]
+        StdErrListener.new do |listener|
+          listener.when(/A site at '.*' already exists/) do
+            throw :nandoc_hack, :site_already_exists
+          end
+        end
+      end
+      ret = nil
+      thing = catch(:nandoc_hack) do
+        ret = super(opts, args)
+        :normal
+      end
+      case thing
+      when :site_already_exists
+        site_already_exists opts, args
+      when :normal
+        ret
+      else
+        fail("hack fail: #{thing.inspect}")
+      end
+    end
+
+    def run_opts_process opts
+      task_abort("you can't have both -M and -m") if
+        opts[:merge_hack] && opts[:merge_hack_reverse]
+      if opts[:datasource]
+        task_abort <<-ABO.gsub(/\n */,"\n").strip
+        for now datasource is hardcoded to be nandoc.
+        usage: #{usage}
+        ABO
+      end
+      opts[:datasource] = 'nandoc'
+      @patch_hack = opts[:patch_hack]
+      nil
+    end
+    private :run_opts_process
+
+  protected
+
+    #
+    # see SupremeStderrHack
+    #
+    def initiate_the_supreme_hack_of_the_standard_error_stream
+      base = Nanoc3::CLI::Base
+      return if base.instance_methods.include?("print_error_orig")
+      base.send(:alias_method, :print_error_orig, :print_error)
+      base.send(:define_method, :print_error) do |error|
+        $stderr = SupremeStderrHack.new($stderr)
+        print_error_orig error
+      end
+    end
+
+
+    def site_already_exists opts, args
+      path = args.first
+      if ! (opts[:merge_hack] || opts[:merge_hack_reverse])
+        task_abort <<-FOO.gsub(/^ +/,'').chop
+          A site at '#{path}' already exists.
+          If you want to try and merge in changes from the site generator
+          (this might just generate a diff), try the --merge-hack (-m) option.
+          see `#{invocation_name} help #{name}` for more information
+        FOO
+      else
+        require File.expand_path('../../support/site-merge.rb', __FILE__)
+        SiteMerge.new(self).site_merge(opts, args)
+      end
+    end
+
+
+
+    #
+    # This is the crux of the whole thing: make the site as the parent
+    # does, then apply the patch.
+    #
+    def site_populate
+      initiate_the_supreme_hack_of_the_standard_error_stream
+      super
+      task = Treebis.dir_task(NanDoc::Root+'/proto/default')
+      task.file_utils = Config.file_utils
+      task.on(FileUtils.pwd).run(:patch_hack => @patch_hack)
+    end
+
+
+    #
+    # Somehow legitimize these awful hacks with an entire class
+    #
+    class StdErrListener
+      def initialize &block
+        @prev = $stderr
+        $stderr = self
+        @expired = false
+        @whens = []
+        block.call(self)
+      end
+      def when regex, &block
+        @whens.push(:regex=>regex, :block=>block)
+      end
+      def puts *args
+        if @expired
+          fail("hack failed when trying to write: #{str}")
+        elsif args.size != 1
+          expire!
+          $stderr.puts(*args)
+        else
+          found = @whens.detect{|x| x[:regex] =~ args.first}
+          if found
+            expire!
+            found[:block].call
+          else
+            expire!
+            $stderr.puts(*args)
+          end
+        end
+      end
+      alias_method :write, :puts # supreme & problematic
+    private
+      def expire!
+        $stderr = @prev
+        @expired = true
+      end
+    end
+
+
+    class SupremeStderrHack
+      #
+      # ridiculous: make a state machine that rewrites part of the error
+      # message coming from nanoc, then gets rid of itself when it's done.
+      # This is so fragile and stupid but I really needed to get the nanoc
+      # message ("please file bug reports") out of the error message so ppl
+      # don't misfile bug reports there that are actually NanDoc bugs.
+      #
+
+      def initialize real
+        @ui = real
+        @state = :looking_for_error_header
+      end
+      def puts *a
+        case @state
+        when :looking_for_error_header
+          if a.first && a.first.include?('/!\ ERROR /!\\')
+            @state = :waiting_for_end_of_error_box
+            @ui.puts <<-HERE.gsub(/^ +/,'')
+           +--- /!\ ERROR /!\ --------------------------------------------+
+           | An exception occured while running nandoc. If you think this |
+           | is a bug in nandoc (likely), please report it at             |
+           | <http://github.com/hipe/nandoc/issues> -- thanks!            |
+           | (it is very likely a treebis patch failure)                  |
+           +--------------------------------------------------------------+
+           HERE
+          else
+            @ui.puts(*a) # probably just whitespace?
+          end
+        when :waiting_for_end_of_error_box
+          if a.first && a.first =~ /\+-+\+/
+            $stderr = @ui
+            @state = :hack_failed
+              # nothing should be callig our puts() method any more
+          end
+        when :hack_failed
+          fail("hack failed")
+        else
+          fail("huh?")
+        end
+      end
+      def write *a
+        @ui.write(*a)
+      end
+    end
+  end
+end