legal_markdown 0.1.3 → 0.1.4

data/README.md

@@ -2,7 +2,7 @@
 
 This gem will parse YAML Front Matter of Markdown Documents. Typically, this gem would be called with a md renderer, such as [Pandoc](http://johnmacfarlane.net/pandoc/), that would turn the md into a document such as a .pdf file or a .docx file. By combining this pre-processing with a markdown renderer, you can ensure that both the structured content and the structured styles necessary for your firm or organization are more strictly enforced. Plus you won't have to deal with Word any longer, and every lawyer should welcome that. Why? Because Word is awful. 
 
-Gitlaw is markdown agnostic at this point and needs to be called independently of any markdown renderer. It is easy enough to build it into your work flow by editing the way that your markdown renderer is called. For instance you can call this file just before pandoc builds it. I use Sublime Text 2 with the Pandown plugin to build my Pandoc files. So what I would do is [..TODO..].
+Gitlaw is markdown agnostic at this point and needs to be called independently of any markdown renderer. It is easy enough to build it into your work flow by editing the way that your markdown renderer is called. For instance you can call this file just before pandoc builds it. 
 
 ## What Does the Gem Allow For?
 
@@ -20,34 +20,15 @@ After the gem has finished its installation on your system then you can simply t
 
 [YAML](http://www.yaml.org/spec/1.2/spec.html) is about the easiest thing to create. At the top of your file (it MUST be at the top of the file) you simply put in three or more hyphens like so: `---` on a single line. Then on the next line you simply put in the `field` followed by a `:` (colon) followed by the `value`. For each line you put the `[field]: [value]` until you have filled everything in that you need. After you have put in all your YAML front-matter then you simply put in a single line with three more hyphens `---` to signal to the gem that it is the end of the fields. So this would look like this:
 
-    ```
-    ---
-    title: My Perfect Contract
-    author: Watershed Legal Services
-    date: 2013-01-01
-    ---
-    ```
+```
+---
+title: My Perfect Contract
+author: Watershed Legal Services
+date: 2013-01-01
+---
+```
 
-## A Few Signals to the Parser
-
-### Leaving the YAML Front-Matter
-
-The gem will normally strip out the YAML front-matter as most markdown renderers will not be sure what to do with such content. Indeed, pandoc will end up drawing a table with the data still there. However, because some could potentially want to use this gem in combination with something like [Jekyll](https://github.com/mojombo/jekyll/) or any other system that could use the YAML front-matter there is a special trigger that tells legal_markdown to leave the YAML front-matter in the file. Legal_markdown will still make the necessary changes to the text of the file but it will not strip out the YAML front-matter in the process of making those changes. 
-
-To leave the YAML front-matter there simply pass the `value` of `true` to the `field` called `leave_yaml_front_matter`; this is how it would look in the above example. 
-
-    ```
-    ---
-    title: My Perfect Contract
-    author: Watershed Legal Services
-    date: 2013-01-01
-    leave_yaml_front_matter: true
-    ---
-    ```
-
-If you do not add the `true` value to the field then the default which is set to false will be triggered and the YAML Front-Matter will be stripped.
-
-### Some Pandoc-Specific Fields
+## Some Pandoc-Specific Fields
 
 There are a few fields that will be treated uniquely. The three fields in the example above (title: , author: , and date: ) will be replaced with the Pandoc fields as appropriate. Perhaps later we can (as a community) build out this functionality for other renderers but for now I've only built it to use Pandoc. If you don't use Pandoc then you can simply omit these fields and there will be no problem. 
 
@@ -57,22 +38,11 @@ Mixins are straight-forward they are simple markers that can be used throughout
 
 Mixins are structured in the form of **double curly** brackets (this was taken from IFTTT). So, for a `{{court}}` mixin, the YAML front-matter would look like this:
 
-    ```
-    {{court}}: Regional Court of Hargeisa
-    ```
-
-Mixins can also be used to set up clauses in the alternative in your templates which can be turned on or off within a specific document simply by updating the YAML mixin to false. Example of a `{{provision12a}}{{provision12b}}` alternative structuring for a contract template. Within the template the YAML front-matter would be structured something like this:
-
-    ```
-    {{provision12a}}: "For the purposes of this Agreement"
-    {{provision12b}}: "This Agreement shall"
-    ```
+```
+{{court}}: Regional Court of Hargeisa
+```
 
-Then to chose one of the two provisions you would would simply change the line to "false" but without the quotes. Example:
-
-    ```
-    {{provision12a}}: false
-    ```
+If you do not want a mixin turned on for a particular document just add the mixin in the YAML Frontmatter and then leave it blank. Legal_markdown will replace the mixin with an empty string so in  the parsed document it will be out of your way.
 
 # Structured Headers
 
@@ -101,68 +71,100 @@ Sometimes in legal documents (particularly in laws) you want to build multiple s
 
 This functionality is built in with a `no-reset` function. You simply add a `no-reset` field to your YAML header and note the headers that you do not want to reset by their l., ll. notation. Separate those levels you do not want reset with commas. Example YAML line:
 
-    ~~~
-    no-reset: l., ll., lll.
-    ~~~
+```
+no-reset: l., ll., lll.
+```
 
 This will not reset level-1, level-2, or level-3 when it is parsing the document and those levels will be numbered sequentially through the entire block rather than reseting when going to a higher block, levels not in this reset, e.g., llll. and lllll. will be reset when going up a level in the tree. Obviously the level 1 headers will never reset.
 
+## No Indent Function
+
+Sometimes you will not want to use Pandoc's listing function. Basically if you are outputting to .pdf, .odt, .doc(x) you may want to keep tight to the margins. This functionality is built into legal_markdown with a `no-indent` function. You simply add a `no-ident` field to your YAML header and not the headers you do not want to indent by their l., ll. notation. Separate those levels you do not want to reset with commas as with the `no-reset` function. Any levels *below* the last level in the `no-indent` function will be indented four spaces.
+
+## Optional Clauses Function
+
+When building templates for contracts, you often build in optional clauses or you build clauses that are mutually exclusive to one another. This functionality is supported by legal_markdown. This is how you build an optional clause. In the body of your text you put the entire clause in square-brackets (as you likely normally would) and at the beginning of the square bracket you put a mixin titled however. In the YAML Front-Matter you simply add true or false to turn that entire clause on or off. **Note**, if you do not add the mixin to your header, legal_markdown is just going to leave it as is. 
+
+You are able to nest one optional clause inside of another. However, if you do so, make sure that you include all of the sub-provisions of the master provision in the YAML matter, else legal_markdown will not be able to understand when it should close the optional provision. Another thing to note, if you include nested provisions, you can turn off an inside provision and leave an outside provision on, but if you turn off an outside provision you cannot turn on an inside provision.
+
+So, this is how the body of the text would look.
+
+```
+[{{my_optional_clause}}Both parties agree that upon material breach of this agreement by either party they will both commit suicide in homage to Kurt Cobain.]
+```
+
+Then the YAML Front Matter would look like this
+
+```
+my_optional_clause: true
+```
+
+or
+
+```
+my_optional_clause: false
+```
+
+I don't know why you would ever write such a clause, but that is why the functionality exists! 
+
 ## Example
 
 If you use a system like Pandoc you can establish a system wherein the styles that you establish in the reference.docx or reference.odt or the latex style references can make up for the lack of granular fuctionality. When you build your reference.odt for example and you want to have a contract look like this:
 
+```
 Article 1. Provision for Article 1.
 
-  Section 1.1. Provision for Section 1.1. 
+    Section 1.1. Provision for Section 1.1. 
 
-    1.1.1 Provision for 1.1.1.
+        1.1.1 Provision for 1.1.1.
 
-    1.1.2 Provision for 1.1.2.
+        1.1.2 Provision for 1.1.2.
 
-  Section 1.2. Provision for Section 1.2.
+    Section 1.2. Provision for Section 1.2.
 
-    1.2.1 Provision for 1.2.1.
+        1.2.1 Provision for 1.2.1.
 
-    1.2.2 Provision for 1.2.2.
+        1.2.2 Provision for 1.2.2.
 
 ...
+```
 
 You can easily to that by doing the following steps.
 
 ### Step 1: Type the body
 
-    ```
-    l. Provision for Article 1.
-    ll. Provision for Section 1.1.
-    lll. Provision for 1.1.1.
-    lll. Provision for 1.1.2.
-    ll. Provision for Section 1.2.
-    lll. Provision for 1.2.1.
-    lll. Provision for 1.2.2.
-    ```
+```
+l. Provision for Article 1.
+ll. Provision for Section 1.1.
+lll. Provision for 1.1.1.
+lll. Provision for 1.1.2.
+ll. Provision for Section 1.2.
+lll. Provision for 1.2.1.
+lll. Provision for 1.2.2.
+```
 
 ### Step 2: (Optional) Fill out the YAML Front-Matter
 
-    ```
-    ---
-    title: Wonderful Contract
-    author: Your Name
-    date: today
-    level-1: 1.
-    level-2: A.
-    level-3: a.
-    ---
-    ```
+```
+---
+title: Wonderful Contract
+author: Your Name
+date: today
+level-1: 1.
+level-2: A.
+level-3: a.
+---
+```
 
 ### Step 3: Modify your reference.odt or reference.docx
 
 In Libreoffice you would modify your template reference.odt as you need it. You would go to Format -> Bullets and Numbering -> Options. 
 
-    1. First you would select Level 1 (on the left). In the Before field you would add "Article " (without the quotes, but not the space). In the After field you would add a period. In the Numbering field you would select 1, 2, 3, .... And in the Show sublevels field you would choose 1
-    2. Second you would select Level 2 (on the left). In the Before field you would add "Section " (without the quotes, but with the space). In the After field you would add a period. In the Numbering field you would select 1, 2, 3, .... And in the Show sublevels field you would choose 2.
-    3. Third you would select Level 3 (on the left). In the Before field you would add nothing (to accomplish the above desired output). In the After field you would add a period. in the Show sublevels field you would choose 3.
-    4. Lastly you would make sure that Consecutive Numbering (field at the bottom) was turned off. 
-    5. You can make sure that all the indenting is as desired in the Position Tab. 
+1. First you would select Level 1 (on the left). In the Before field you would add "Article " (without the quotes, but not the space). In the After field you would add a period. In the Numbering field you would select 1, 2, 3, .... And in the Show sublevels field you would choose 1
+2. Second you would select Level 2 (on the left). In the Before field you would add "Section " (without the quotes, but with the space). In the After field you would add a period. In the Numbering field you would select 1, 2, 3, .... And in the Show sublevels field you would choose 2.
+3. Third you would select Level 3 (on the left). In the Before field you would add nothing (to accomplish the above desired output). In the After field you would add a period. in the Show sublevels field you would choose 3.
+4. Lastly you would make sure that Consecutive Numbering (field at the bottom) was turned off. 
+5. You can make sure that all the indenting is as desired in the Position Tab. 
 
 Then you would save the reference.odt as a new name perhaps contract-reference.odt in your Pandoc reference folder. 
 
@@ -172,16 +174,16 @@ Then you would save the reference.odt as a new name perhaps contract-reference.o
 
 Now that you've been warned, here's how you use precursors. Within the text of the document nothing changes. In the YAML front matter you will leave it as it was before. All you need to do is add any word or other marker before the trigger. What `legal_markdown` will do is to look at the last two characters if the marker ends in a period or three if it ends in a paren, and then everything else it will place into a precursor. If you want to reference the preceding level (like 1.1.1 in the example above) then simply put in {pre}. I'll try to make this less fragile down the road, but for now it is what it is. So, your YAML front matter will look like this:
 
-    ```
-    ---
-    title: Wonderful Contract
-    author: Your Name
-    date: today
-    level-1: Article 1.
-    level-2: pre 1.
-    level-3: pre a.
-    ---
-    ```
+```
+---
+title: Wonderful Contract
+author: Your Name
+date: today
+level-1: Article 1.
+level-2: pre 1.
+level-3: pre a.
+---
+```
 
 The other thing you need to be aware of if you use this method is that when `legal_markdown` parses the input markdown it have to hardcode in the numbering. This means that you'll lose any features of automatic lists and list nesting which your markdown renderer may give you if you simply placed the triggers without any precursors.
 
@@ -197,35 +199,33 @@ I do not use latex to create pdfs nor do I use Word, but the functionality will
 * If you use the reference.odt or reference.docx to override the default formating of the list then it is not optimal add level-1 or level-2 leading text or utilize the different marker functionality (e.g., (i) or (a) and the like) to the YAML front-matter. The optimal way is to use the defaults that pandoc has or whatever renderer you use along with legal_markdown to set the spacing and then use the reference styles to build the functionality that you would like from the word processor side. The leading text and different marker systems are predominately built for html output.
 * Legal_markdown is optimized primarily for contracts, legislation, and regulations. It is not optimized for cases. For memoranda and filings I use the mixin portion but not the header portion which is enough to meet my needs - in particular, when matched with Sublime Text snippets. If you area looking for a more complete solution for cases and filings I would recommend the [Precedent Gem](https://github.com/BlackacreLabs/precedent) built by [Kyle Mitchell](https://github.com/kemitchell) for [Blackacre Labs](https://github.com/BlackacreLabs)
 
-# TODO
-
-[ ] Definitions. For now these can be used as mixins but that functionality needs to improve.
-
-[ ] Make a no-reset option for certain levels that should not reset when moving up the tree.
-
-[ ] Parsing. At this point legal_markdown cannot take a markdown document and parse it to build structured headers. Legal_markdown only works with a renderer to *create* documents but not to *import* documents. I want to build this functionality out at a later date. Legal_markdown is not meant as an importer for files types, there are other tools for that but I would like it to be able to parse text that is already in markdown. 
-
-[ ] Markdown post-processing. This will cure some of the issues (class establishment and proper list nesting of structure documents) that are currently lost when using precurors.
-
-[ ] Different input and output files.
-
-[ ] Implement partials.
-
-[ ] Small capitals based on [Precedent's Syntax](https://github.com/BlackacreLabs/precedent/blob/master/SYNTAX.md).
-
-[ ] Handle against multiple blocks in a document as this currently will not work.
+# Roadmap / TODO
+
+- [X] Make a no-reset option for certain levels that should not reset when moving up the tree.
+- [X] Make no indent option.
+- [X] Optional clauses in brackets with a mixin inside. Turn the mixin to false and the whole clause will not be rendered. For a mixin that simply turns on or off, must make a function whereby the mixin is true that it is turned on. 
+- [ ] Handle Exceptions better as it is very brittle right now.
+- [ ] Different input and output files.
+- [ ] Implement partials.
+- [ ] Leave the YAML Front Matter
+- [ ] Definitions. For now these can be used as mixins but that functionality needs to improve.
+- [ ] Date = today function.
+- [ ] Handle against multiple blocks in a document as this currently will not work.
+- [ ] ??? Should this switch to TOML rather than YAML frontmatter...?
+- [ ] legal2md functionality. At this point legal_markdown cannot take a markdown document and parse it to build a structured legal document. Legal_markdown only works with a renderer to *create* documents but not to *parse* legal documents to create markdown. 
 
 # Contributing
 
-1. Fork it
-2. Create your feature branch (`git checkout -b my-new-feature`)
-3. Commit your changes (`git commit -am 'Add some feature'`)
-4. Push to the branch (`git push origin my-new-feature`)
-5. Create new Pull Request
+1. Fork the repository.
+2. Create your feature branch (`git checkout -b my-new-feature`).
+3. Add Tests (and feel free to help here since I don't (yet) really know how to do that.).
+4. Commit your changes (`git commit -am 'Add some feature'`).
+5. Push to the branch (`git push origin my-new-feature`).
+6. Create new Pull Request.
 
 # License
 
-MIT License - (c) 2012 - Watershed Legal Services, PLLC. All copyrights are owned by [Watershed Legal Services, PLLC](http://watershedlegal.com). See License file.
+MIT License - (c) 2013 - Watershed Legal Services, PLLC. All copyrights are owned by [Watershed Legal Services, PLLC](http://watershedlegal.com). See License file.
 
 This software is provided as is and specifically disclaims any implied warranties of fitness for any purpose whatsoever. By using this software you agree to hold harmless Watershed Legal Services and its Members for any perceived harm that using this software may have caused you. 
 

data/lib/legal_markdown/version.rb

@@ -1,3 +1,3 @@
 module LegalMarkdown
-  VERSION = "0.1.3"
+  VERSION = "0.1.4"
 end

data/lib/legal_markdown.rb

@@ -84,19 +84,67 @@ module LegalMarkdown
   # Mixins
 
   def mixing_in( mixins, content )
-    mixins.each do | mixin, replacer |
-      replacer = replacer.to_s
-      safe_words = [ "title", "author", "date" ]
-      if replacer != "false"
-        pattern = /{{#{mixin}}}/
-        if content =~ pattern
-          content = content.gsub( pattern, replacer )
-          # delete the mixin so that later parsing of special mixins & headers is easier and faster
-          mixins.delete( mixin ) unless safe_words.any?{ |s| s.casecmp(mixin) == 0 }
+
+    def clauses_mixins( mixins, content )
+      clauses_to_delete = []
+      clauses_to_mixin = []
+      
+      mixins.each do | mixin, replacer |
+        replacer = replacer.to_s.downcase
+        clauses_to_delete << mixin if replacer == "false"
+        clauses_to_mixin << mixin if replacer == "true"
+      end
+      
+      clauses_to_delete.each { |m| mixins.delete(m) }
+      clauses_to_mixin.each { |m| mixins.delete(m) }
+
+      until clauses_to_delete.size == 0
+        clauses_to_delete.each do | mixin |
+          pattern = /(\[{{#{mixin}}}\s*)(.*?\n?)(\])/m
+          sub_pattern = /\[{{(\S+)}}/m
+          content[pattern]
+          get_it_all = $& || ""
+          sub_clause = $2 || ""
+          next if sub_clause[sub_pattern] && clauses_to_delete.include?($1)
+          content = content.gsub( get_it_all, "" )
+          clauses_to_delete.delete( mixin )
+        end
+      end
+
+      until clauses_to_mixin.size == 0
+        clauses_to_mixin.each do | mixin |
+          pattern = /(\[{{#{mixin}}}\s*)(.*?\n?)(\])/m
+          sub_pattern = /(\[{{\S+}})/m
+          content[pattern]
+          get_it_all = $& || ""
+          sub_clause = $2 || ""
+          next if sub_clause[sub_pattern] && clauses_to_mixin.include?($1)
+          content = content.gsub( get_it_all, sub_clause )
+          clauses_to_mixin.delete( mixin )
+        end
+      end
+
+      return [content, mixins]
+    end
+
+    def normal_mixins( mixins, content )
+      mixins.each do | mixin, replacer |
+        unless mixin =~ /level-\d/ or mixin =~ /no-reset/ or mixin =~ /no-indent/
+          replacer = replacer.to_s
+          safe_words = [ "title", "author", "date" ]
+          pattern = /({{#{mixin}}})/
+          if content =~ pattern
+            content = content.gsub( $1, replacer )
+            mixins.delete( mixin ) unless safe_words.any?{ |s| s.casecmp(mixin) == 0 }
+          end
         end
       end
+      return [content, mixins]
     end
-    return [content, mixins]
+
+    clauses_mixed = clauses_mixins( mixins, content )
+    mixed = normal_mixins( clauses_mixed[1], clauses_mixed[0] )
+    return [ mixed[0], mixed[1] ]
   end
 
   # ----------------------
@@ -176,6 +224,10 @@ module LegalMarkdown
           no_subs_array = value.split(", ")
           no_subs_array.each{|e| substitutions[e][6] = :no_reset }
         end
+        @no_indt_array = []
+        if header =~ /no-indent/
+          @no_indt_array = value.split(", ")
+        end
       end
 
       return substitutions
@@ -235,8 +287,12 @@ module LegalMarkdown
 
       def log_the_line( new_block, selector, line, array_to_sub )
         substitute = array_to_sub[1..4].join
-        spaces = ( " " * ( (selector.size) - 1 ) * 4 )
-        new_block << spaces + line.gsub(selector, substitute)
+        spaces = ""
+        unless @no_indt_array.include?(selector)
+          downgrade_spaces = @no_indt_array.include?("l.") ? @no_indt_array.size - 1 : @no_indt_array.size
+          spaces = ( " " * ( (selector.size) - 2 - downgrade_spaces ) * 4 )
+        end
+        new_block << spaces + line.gsub(selector, substitute) + "\n"
       end
 
       def increment_the_branch( hash_of_subs, array_to_sub, selector )
@@ -328,10 +384,8 @@ module LegalMarkdown
         return new_block
       end
 
-      if block != nil && block != "" && substitutions != nil && substitutions != {}
-        substitutions.each_key{ |k| substitutions[k]= get_the_subs_arrays(substitutions[k]) }
-        new_block = reform_the_block( block, substitutions )
-      end
+      substitutions.each_key{ |k| substitutions[k]= get_the_subs_arrays(substitutions[k]) }
+      new_block = reform_the_block( block, substitutions )
     end
 
     headers = get_the_substitutions( headers )
@@ -340,16 +394,15 @@ module LegalMarkdown
     not_the_block = block_noted[1]
     block_noted = ""   # Really only for long documents so they don't use too much memory
 
-    if headers == {} 
-      block_redux = block
-    end
     if block == nil || block == ""
       block_redux = ""
+    elsif headers == {} 
+      block_redux = block
     else
       block_redux = chew_on_the_block( headers, block )
     end
 
-    headed = not_the_block.gsub("{{block}}", block_redux )
+    headed = not_the_block.gsub("{{block}}", block_redux ) 
   end
 
   # ----------------------

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: legal_markdown
 version: !ruby/object:Gem::Version
-  version: 0.1.3
+  version: 0.1.4
   prerelease: 
 platform: ruby
 authors:
@@ -9,7 +9,7 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2013-02-22 00:00:00.000000000 Z
+date: 2013-03-02 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: roman-numerals
@@ -63,7 +63,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
       version: '0'
       segments:
       - 0
-      hash: 1157519025930477197
+      hash: -1663138300287536069
 required_rubygems_version: !ruby/object:Gem::Requirement
   none: false
   requirements:
@@ -72,7 +72,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
       segments:
       - 0
-      hash: 1157519025930477197
+      hash: -1663138300287536069
 requirements: []
 rubyforge_project: 
 rubygems_version: 1.8.25