Merge pull request #62 from hfm/fix-markdown

Fix markdown

README.markdown

@@ -1,8 +1,8 @@
 [![Build Status](https://travis-ci.org/puppetlabs/puppetlabs-hocon.png?branch=master)](https://travis-ci.org/puppetlabs/puppetlabs-hocon)
 
-#HOCON file
+# HOCON file
 
-####Table of Contents
+#### Table of Contents
 
 1. [Overview](#overview)
 2. [Module Description - What the module does and why it is useful](#module-description)
@@ -13,21 +13,21 @@
 5. [Reference - An under-the-hood peek at what the module is doing and how](#reference)
 6. [Development - Guide for contributing to the module](#development)
 
-##Overview 
+## Overview
 
 This module adds resource types to manage settings in HOCON-style configuration files.
 
-##Module Description
+## Module Description
 
 The hocon module adds a resource type so that you can use Puppet to manage settings in HOCON configuration files.
 
-##Setup
+## Setup
 
-##Beginning with hocon
+## Beginning with hocon
 
 To manage a HOCON file, add the resource type `hocon_setting` to a class.
 
-##Usage
+## Usage
 
 Manage individual settings in HOCON files by adding the `hocon_setting` resource type to a class. For example:
 
@@ -73,16 +73,16 @@ hocon_setting { 'sample map setting':
 }
 ```
 
-##Reference
+## Reference
 
-###Type: hocon_setting
+## #Type: hocon_setting
 
 #### Parameters
 
 * `ensure`: Ensures that the resource is present. Valid values are 'present', 'absent'.
 
 * `path`: The HOCON file in which Puppet will ensure the specified setting.
-  
+
   This parameter, along with `setting`, is one of two namevars for the
   `hocon_setting` type, meaning that Puppet will give an error if two `hocon_setting` resources have the same `setting`
   and `path` parameters.
@@ -92,26 +92,26 @@ hocon_setting { 'sample map setting':
 * `setting`: The name of the HOCON file setting to be defined. This can be a top-level setting or a setting nested
   within another setting. To define a nested setting, give the full path to that setting with each level separated
   by a `.` So, to define a setting `foosetting` nested within a setting called `foo` contained on the top level,
-  the `setting` parameter would be set to `foo.foosetting`. 
-  
+  the `setting` parameter would be set to `foo.foosetting`.
+
   This parameter, along with `path`, is one of two namevars for the
   `hocon_setting` type, meaning that Puppet will give an error if two `hocon_setting` resources have the same `setting`
-  and `path` parameters. 
-  
+  and `path` parameters.
+
   If no `setting` value is explicitly set, the title of the resource will be used
   as the value of `setting`.
 
 * `value`: The value of the HOCON file setting to be defined.
 
 * `type`: The type of the value passed into the `value` parameter. This value should be a string, with valid values being
     `'number'`, `'boolean'`, `'string'`, `'hash'`, `'array'`, `'array_element'`, and `'text'`.
-    
+
     This parameter will not be need to be set most of the time, as the module
     is generally smart enough to figure this out on its own. There are only three cases in which this parameter is required.
-    
+
     The first is the case in which the `value` type is a single-element array. In that case, the `type` parameter will need to be set to
     `'array'`. So, for example, to add a single-element array, you would add the following to your manifest
-    
+
     ```
     hocon_setting { 'single array setting':
       ensure => present,
@@ -142,28 +142,28 @@ hocon_setting { 'sample map setting':
     In this case, `value` must be a string with no leading or trailing whitespace, newlines, or comments that contains a valid HOCON value, and the
     `type` parameter must be set to `'text'`. This is an advanced use case, and will not be necessary for most users. So, for example, say you want to
     add a map with particular indentation/comments into your configuration file at path `foo.bar`. You could create a variable like so
-    
+
     ```
-    $map = 
+    $map =
     "{
         # This is setting a
         a : b
         # This is setting c
             c : d
      }"
     ```
-    
+
     And your configuration file looks like so
-    
+
     ```
     baz : qux
     foo : {
       a : b
     }
     ```
-    
+
     You could then write the following in your manifest
-    
+
     ```
     hocon_setting { 'exact text setting':
       ensure => present,
@@ -173,9 +173,9 @@ hocon_setting { 'sample map setting':
       type => 'text',
     }
     ```
-    
+
     And the resulting configuration file would look like so
-    
+
     ```
     baz : qux
     foo : {
@@ -188,18 +188,18 @@ hocon_setting { 'sample map setting':
       }
     }
     ```
-    
+
     Aside from these three cases, the `type` parameter does not need to be set.
 
-##Development
- 
+## Development
+
 Puppet Labs modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can’t access the huge number of platforms and myriad of hardware, software, and deployment configurations that Puppet is intended to serve.
 
 We want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
 
 You can read the complete module contribution guide on the [Puppet Labs wiki](http://projects.puppetlabs.com/projects/module-site/wiki/Module_contributing).
 
-##Contributors
+## Contributors
 
 The list of contributors can be found at: [https://github.com/puppetlabs/puppetlabs-hocon/graphs/contributors/contributors](https://github.com/puppetlabs/puppetlabs-hocon/graphs/contributors/contributors).