anchor.diff:  |===
   ----
   
  -Which is rendered as
  +This is rendered as:
   
   [options="header, autowidth"]
   |===
  
positive.code: 
  == Comments
  
  There's a separate build including comments.
  The comments show up with a yellow background.
  This build doesn't run by default, but after a normal build, you can use `make annotated` to build it.
  You can also use the resulting page to search for content, as the full manual is on a single page.
  
  Here's how to write a comment:
  
  [source]
  ----
  // this is a comment
  ----
  
  The comments are not visible in the normal build.
  Comment blocks won't be included in the output of any build at all.
  Here's a comment block:
  
  [source]
  ----
  
negative.code: 
  [[doc-guidelines-writing]]
  == Writing
  The following rules wil help you to commit correctly formatted and prepared documentation for inclusion in the OpenNMS project.
  It is important that we maintain a level of consistency across all of our commiters and the documentation they produce.
  
  When writing place a single sentence on each line.
  This makes it easy to move content around, and also easy to spot long, or fragmented, sentences.
  This will also allow us to assign comments on a sentence in GitHub which will facilitate easier merging.
  
  NOTE: Other than writing documentation, you can help out by providing comments on documentation, reviewing, suggesting improvements or reporting bugs.
  To do this head over to: http://issues.opennms.org/browse/NMS/component/10011[issue tracker for documentation]!
  
  [[doc-guidelines-conventions]]
  === Conventions for text formatting
  The following conventions are used:
  
  * File names and path are written in `'poller-configuration.xml'` they will be rendered in: 'poller-configuration.xml';
  * Names that indicate special attention, e.g. this configuration matches \*any* entry: this is rendered as: this configuration matches *any* entry;
  * \_Italics_ is rendered as _Italics_ and used for emphasis and indicate internal names and abbreviations;
  * \*Bold* is rendered as *Bold* and should be used sparingly, for strong emphasis only;
  * \+methodName()+ is rendered as +methodName()+ and is also used for literals,
    (note: the content between the `+` signs _will_ be parsed);
  * \`command` is rendered as `command` (typically used for command-line or parts used in configuration files),
    (note: the content between the +`+ signs _will not_ be parsed);
  * Mono\+\+space\++d is rendered as Mono++space++d and is used for monospaced letters;
  * \'my/path/' is rendered as 'my/path/' this is used for file names and paths;
  * \\``double quote'' (which is two grave accents to the left and two acute accents to the right) renders as ``double quote'';
  * \`single quote' (which is a single grave accent to the left and a single acute accent to the right) renders as `single quote'.
  
  [[doc-guidelines-gotchas]]
  === Gotchas
  
  * Always leave a blank line at the top of the documents section.
  It might be the title ends up in the last paragraph of the document;
  * Always leave a blank line at the end of documents;
  * As +{}+ are used for Asciidoc attributes, everything inside will be treated as an attribute.
    To avoid this you have to escape the opening brace: +\\{+.
    If you do not escape the opening brace, the braces and the text inside them will be removed without any warning being issued!;
  * Forcing line breaks can be achieved with ` +` at the end of the line followed by a line break.
  
  .Example in source force line break
  [source]
  