mint 0.1

data/README.md

@@ -0,0 +1,437 @@
+*The following is a **rough draft** of the current Mint design, along with my future plans for the library and tool.*
+
+Possible taglines
+-----------------
+
+I don't actually believe in tag lines, but if Mint were to have one, it might be one of these:
+
+- Value your words. Leave the formatting up to us.
+- Reuse your ideas. Reuse your formats. Keep them Mint fresh.
+- Mint once, remix as needed.
+
+Introduction
+------------
+
+Mint is an agile, lightweight solution for your documents.
+
+Mint manages your documents in a decentralized way. It frees you from bloated word processors. Mint brings together standards and common templating languages for a clean, agile approach to documents. It uses HTML outside of the web. Leverages text for tons of different views. Keeps your data and formatting separate. In a word: simplifies. In a couple of words: kicks ass.
+
+In a few more: *Mint processes words so you don't have to.*
+
+Table of contents
+-----------------
+
+I. Use cases  
+II. The Mint library  
+III. Designing a template  
+IV. The Mint path  
+V. The `mint` command   
+VI. Future directions and tools
+
+I. Use cases
+------------
+
+1. Jake has text files formatted as Markdown-style text. He has traditionally published these as blog entries, which works well because his webserver takes care of processing the Markdown, generating HTML, and styling it with his static CSS. Jake has no way of visualizing his documents without a webserver running. He likes the convenience of centralized CSS styles that he can update once and cascade everywhere. He does not like depending on a webserver for static pages. Jake wants a document management system where source files are written in Markdown but are "printed" into HTML and styled with centralized sheets he creates himself.
+
+2. Donna has traditionally used a WYSIWYG word processor to create, edit, version, and present ideas in her personal and school life (not work). She wants her documents to exist forever without breaking standards: she wants them to be completely future-compatible. Therefore, she wants to migrate away from her proprietary word processor. She wants a migration tool to make the initial conversion. Interoperability with other people is not required. As long as she can view and print formatted documents, keeping source files as plaintext, she is happy.
+
+3. Bertrande wants to build a styles gallery that previews certain styles on Textile-formatted documents using a web application... (finish later)
+
+4. Marina wants to convert all her proprietary processed documents to Markdown for future compatibility, but wants to share these documents with friends at work. Interoperability is important here. The friends should be able to easily view *and* edit *and* annotate all documents.
+
+II. The Mint library
+--------------------
+
+This section discusses the Mint library API. Read on for the mint binary.
+ 
+### A basic Mint document ###
+
+Mint is loaded with smart defaults, so if you don't want to configure something--say, the basic HTML skeleton of your document or the output name or director--you don't have to. You'll probably be surprised at how easy it is to use out of the box, and how configurable it is.
+
+  document = Document.new '~/Documents/Minimalism.md'
+  document.press
+  
+And voilà, you will find the following next to Minimalism.md in the same directory:
+
+- Minimalism.html
+- styles/default.css
+
+Opening Minimalism.html with your favorite web browser--[Firefox is best for typography][Firefox typography]--will show what looks like a word processed document, complete with big bolded headers, italic emphasis, automatically numbered lists, and bullets.
+
+Sending that page to a printer is as easy as clicking "Print" from your browser. What comes out of your printer will have a 12 pt base font, normal margins, and a not-too-cramped baseline. (Ah the wonder of print stylesheets.)
+
+If you want to customize your document, though--and that's why I built this library--Mint makes that easy.
+
+[Firefox typography]: http://opentype.info/blog/2008/06/14/kerning-and-opentype-features-in-firefox-3/ "Firefox 3 supports kerning and automatic ligatures"
+
+### Customizing Mint ###
+
+To understand how the library works, with and without configuration, it is helpful to look at the options you can pass to the library and what their defaults are.
+
+You can pass any of the following to a new document:
+
+- `:layout` and `:style` are names of templates or file names.
+
+  Defaults:
+    
+        :layout => 'default'  
+        :style => 'default'
+
+  Notes:
+  
+  1. If you specify a template name here, Mint will search its paths in order (see **The Mint Path** for more details) for a template with that name. A template file looks like the following:
+
+        PATH/templates/TEMPLATE_NAME/style.sass
+        PATH/templates/TEMPLATE_NAME/layout.haml
+
+  2. If you specify a template name, it MUST be a simple name without extensions or directories included. Also, it must not be the name of a file in the working directory. (It is unlikely you'll have an extension-less file named 'normal' or 'default' in your working directory.)
+
+  3. You can include path information if you're specifying a source file instead of a template name. If you do specify a file, the path/file will be resolved from the directory where you're calling Mint (the 'working directory'). If you're going to use Mint this way (and I don't see this as more than a temporary solution) you'll probably want to call Mint from the context of your source directory. Alternatively, you can use [`Dir.chdir`][Dir::chdir method] for the same effect.
+
+  4. You can specify nil if you don't want a style to be rendered. This is useful if you're pointing a lot of documents to one stylesheet and only want to Mint the stylesheet one time.
+
+- `:root` is the root context of the final document. That is, the output. All relative *output* paths are resolved from the root path. `:root` itself must be an absolute path or nil. In most cases where you want a relative `:root`, try using `:destination`, instead. `:root` is most useful when compiling several source documents from different folders into a single, centralized directory.
+  
+  Default:
+  
+        :root => nil
+  
+  Notes:
+  
+  1. If nil, `:root` defaults to your content's parent directory.
+  2. `:root` MUST be a directory.
+
+- `:destination` lets you specify a subdirectory for your output. There is an option to specify a separate `:style_destination`. The former is resolved relative to `:root`. The latter is resolved relative to `:destination`.
+
+  Defaults:
+
+        :destination => nil  
+        :style_destination => nil
+
+  Notes:
+
+  1. `:destination` MUST refer to a directory and *not* a file. If you want to specify the output file name, use the `:name` parameter.
+
+  2. Mint resolves `:destination` relative to `:root` and serves as a way of organizing output files. `:style_destination` is resolved relative to `:destination` so that packaging styles inside document directories is easy. (This supports the common case where you will want a subdirectory called `'styles'` to hold your style files.)
+
+  3. If either value is nil, it is simply ignored.
+  
+- `:name` is the name of the output file, which will end up in `/:root/:destination/`. `:style_name` is the name of the stylesheet output file and will show up in `/:root/:destination/:style_destination/`.
+  
+  Defaults:
+  
+        :name => nil
+        :style_name => nil
+
+  Notes:
+
+  1. If nil, the name of a Document or stylesheet comes from it's source file. (Minimalism.md will turn into Minimalism.html without configuration.)
+
+In summary: if `:root` is unspecified, it will be the directory where your content file. The rendered content and style files will be placed directly into this directory unless given a specific `:destination`. The output names will come from their source files unless you specify `:name`.
+
+Without configuration, `destination = root = content.dirname.expand_path`
+
+### Examples ###
+
+At this point, a couple of example may be useful.
+
+The following are possible:
+
+  content = '~/Documents/Minimalism.md'
+
+  Document.new content
+  
+  Document.new content, :root => '~/Documents/Final', :destination => 'directory', :name => 'final.html'
+  Document.new content, :root => 'directory'
+  Document.new content, :root => 'directory', :destination => 'subdirectory'
+  
+  Style.new 'normal'
+  Style.new '~/Sites/Commons/style/normal.sass', :destination => 'style', :name => 'normal.css' # :destination is converted to :style_destination in the context of a document
+  Style.new '~/Sites/Commons/style/normal.css'
+  Style.new 'Commons/style/normal.css'
+  
+If block-style initiation is your thing:
+
+    Document.new content do |d|
+      d.root = 'my-book'
+      d.name = 'my-book-final-draft.html'
+    
+      d.style 'normal' do |s|
+        s.destination = 'styles'
+        s.name = 'stylesheet.css'
+      end
+    end
+    
+> Note: Block-style indentation passes the block to you after initializing
+> the Document with default values. So you do not need to worry about
+> specifying each argument. Anything you specify will override what is already there.
+
+[Dir::chdir method]: http://ruby-doc.org/core/classes/Dir.html#M002314 "You can change the current directory context with Dir::chdir(path)"
+
+III. Designing a template
+-------------------------
+
+Templates can be written in any format accepted by the Tilt template interface library. (See [the Tilt TEMPLATES file][Tilt templates] for more information.)
+
+Mint gives you convenience methods that you can use in your templates.
+
+### Place your content, point to your styles ###
+
+If you're designing a layout, you need to indicate where Mint should place your content. Therefore, raw HTML files cannot be layouts. Instead, if you want to use HTML templates, you should change the extension to .erb. These files are essentially HTML with the possibility for Ruby calls.
+
+Inside your template, use the keyword (well, actually the method) `content` to place your source's content.
+
+You will want to point to your document's stylesheet (via a relative URL) from within your layout, usually in the `<head/>` element. Use the keyword `stylesheet`.
+
+So if you're writing your layout using Erb, the template might look like this:
+
+    <!doctype html>
+    <html>
+      <head>
+        <link rel='stylesheet' href='<%= stylesheet %>' />
+      </head>
+  
+      <body>
+        <div id='container'>
+          <%= content %>
+        </div>
+      </body>
+    </html>
+
+The same layout in Haml would be:
+
+    !!!
+    %html
+      %head
+        %link{ :rel => 'stylesheet', :href => stylesheet }
+    
+      %body
+        #container= content
+    
+### Style your content ###
+
+You can build stylesheets using [CSS][], [Sass/Scss][] or [Less][].
+
+[Tilt templates]: http://github.com/rtomayko/tilt/blob/master/TEMPLATES.md "A listing of all templates supported by Tilt."
+[CSS]: http://en.wikipedia.org/wiki/Cascading_Style_Sheets
+[Sass/Scss]: http://sass-lang.com/
+[Less]: http://lesscss.org/
+
+Mint comes preloaded with several styles and layouts:
+
+1. Default
+2. Serif Pro
+3. Sans Pro
+4. Protocol
+5. Protocol Flow - requires Javascript
+6. Resume
+
+IV. The Mint path
+-----------------
+
+Mint's path can be useful for a lot of things, especially for extensions and tools that use the library. The most important use for the path in the library is to find named templates.
+
+When given a style or layout name (instead of a file name), Mint will search its paths in order until it finds the appropriate template. If no template is found, it will fall back to the default template.
+
+The default Mint path (in order) is:
+
+- the current working directory
+- HOME_DIRECTORY/.mint
+- /usr/share/mint (or whatever your system uses for system-wide configuration)
+- the gem's source directory (as a final effort)
+
+Templates should be in a directory named templates. Inside this directory, there should be a subdirectory for each template:
+
+- PATH/templates/normal/style.sass
+- PATH/templates/normal/layout.haml
+  
+Normally a style will go best with its complement layout. However, layouts and styles can be mixed and matched at your discretion. This is especially true where you are not using stylesheets to format specific IDs or classes you're expecting to find in your layout. (In other words, this works best when you're focused on typography and not page layout.)
+
+V. The `mint` command
+---------------------
+
+### The basic `mint` command ###
+
+The easiest Mint command doesn't require configuration. It will transform all of your Documents into HTML and link all of them to the default stylesheet, which will be output in the same directory as the source documents.
+
+  mint
+  
+If you have a ./templates/default/ subdirectory, the templates found in that directory will be used.
+  
+This command can be tweaked with options and arguments to be more flexible:
+
+    mint Minimalism.md                  # renders a specific file
+    mint Minimalism.md Final.html       # specifies an output file
+    mint Minimalism.md --style=resume   # specifies a style template
+    mint Minimalism.md --root=~/Documents/Minimalism --style=default --style-destination=styles
+
+### Mint options &amp; shortcuts ###
+
+You can pass several options to `mint`. Each option has a short form.
+
+The following correspond to the parameters you can pass to `Mint::Document.new`, as described in [The Mint library][]:
+
+- `--layout, -L`
+- `--style, -S`
+- `--root, -R`
+- `--destination, -D`
+- `--name, -N`
+- `--style-destination`
+- `--style-name`
+
+Other options have nothing to do with document configuration but are there for convenience:
+
+- `--verbose, -v` - will output all rendering results
+- `--simulation, -s` - will not actually render any files
+
+[The Mint library]: #ii_the_mint_library
+
+### Mint projects ###
+
+A more powerful and reconfigurable version of Mint uses Mint projects. To initialize a project in the current directory:
+
+    mint init 
+
+The following does the same thing, but all documents rendered in this project will use the normal template (both layout and style) by default.
+  
+    mint init --template normal
+
+The following does the same thing, but all documents rendered in this project will use the protocol.haml layout and serif-professional style by default.
+  
+    mint init --layout protocol.haml --style serif-professional
+  
+You will want to make sure that your layouts and styles are compatible. Most text-heavy layouts should be compatible with any style (and Mint is made for text-heavy documents). If you're using Mint with specialized style files, though, and expect certain IDs and classes in your layout document, you will want to check for layout/style compatibility.
+
+A project stores references to all of its documents. You can list documents with:
+
+    mint list
+
+You can find out which documents have been minted (and where), along with any universal templates using:
+
+    mint status
+  
+### Project configuration ###
+
+Mint projects can be associated with [Yaml configuration files][Yaml]. These files are created if you pass any options to `mint init` when you create a project. Alternatively, you can set global configuration options after creating a project:
+
+    mint set --template serif-pro
+
+Projects use configuration files *and not command-line options* to determine how they should behave. You can modify the config file through the command line, but do not use the command line to pass options while minting an entire project.
+
+In other words, this is okay for minting a single file:
+
+    mint --template normal
+    
+It is *not* okay if you are inside a project. In this case, you SHOULD alter the configuration file (via command line or an editor) and then type:
+
+    mint
+  
+The config.yaml file can include the following options:
+ 
+    layout: normal
+    destination: output
+    style: normal
+    style_destination: styles
+    template: resume # overrides layout and style options
+
+[...]
+
+These files give you the power to unify a project with a certain layout and style.
+  
+If configuration options get complicated, it may be useful to list all active defaults:
+
+    mint config
+  
+[Yaml]: http://yaml.org/
+  
+### Editing files in a project ###
+
+Inside of a project directory, you can edit any stylesheet or document template that would normally be used by the project without delving into the Mint templates directories.
+
+    mint edit --layout default    # selects the first template in your path
+    mint edit --style normal      # with the appropriate name
+
+Mint will open the appropriate file in the editor specified by EDITOR. There is a short form for each option:
+
+    mint edit -L normal
+    mint edit -S normal
+
+To remove all mint-generated files in a directory (or for a package):
+
+    mint restore .
+
+VI. The future of Mint
+----------------------
+
+This section documents features that do not yet exist, but that I would like to have in future versions of Mint.
+
+### Possible next steps ###
+
+I might introduce the concept of a project registry. This would allow for interlinking between Mint projects scattered around a system, or perhaps even remotely. (How useful would a remote link be without the Web, though?)
+
+`mint init` would register a project, whose name would be based on its parent directory. The project directory would be a user-wide listing that could allow hyperlinking between separate Mint projects, along with use of common stylesheets. There would also be a manual option:
+
+    mint add --project ~/Projects/NamedProject --name=NamedProject
+
+### Packages ###
+
+Sometimes, it may be useful to "finalize" the design of a document, for example, with publications. The best way I can think of to do this is to package the document's output file along with its style in a zipped package, which can be read by the following:
+
+    mint open --package Minimalism --in firefox
+
+To package a document with its stylesheet, as a sort of a printing:
+
+    mint package document.md --name Document # will get the extension .pkg?
+  
+Eventually, I want this to include multiple output formats, like HTML4, HTML5, PDF and ePub. The format opened by the `mint open` command could be determined by the application you choose to open it with.
+
+When that does happen, you'll also be able to set the default version of the document that will open using:
+
+  mint set --package-default html5
+
+### My dreams about Mint, and where it could go ###
+
+I have more ideas for Mint, but they are probably far-off pipe dreams.
+
+What if Mint were social and a good citizen with respect to data portability? This could look like:
+
+    mint share --user http://davejacobs.myopenid.com/
+    mint share --user =david --service freeXRI
+    mint share --user @dave_jacobs --service twitter
+    mint share --service twitter
+
+For this last command, Mint would upload an HTML to a preconfigured FTP server or web application and then post a link to that document in the recipient's Twitter stream. I'm not sure exactly how this would go.
+
+The configuration file could look something like:
+  
+  services:
+    - twitter:
+        authorization: OAuth
+        key: etc.
+    
+    - openid:
+        url: http://davejacobs.myopenid.com/
+        authorization: OAuth
+        key: etc.
+ 
+Or you could publish multiple output formats, and to multiple locations: 
+        
+  mint publish --ftp default
+  mint publish --blog personal
+
+The configuration:
+  
+  publishers:
+    - ftp:
+      - default:
+          server: ftp.provider.com
+          security: sftp
+          directory: /home/USERNAME/example.com/documents
+    - blog:
+      - personal:
+
+Or you could connect to a service to protect your intellectual property rights:   
+
+    mint copyright
+
+I don't know if this is even possible, but wouldn't it be cool to generate a unique number based on the date, time, and contents of any article published and assign it to the article as a hash of all its metadata. The number would be so complex that you could not generate it without all the appropriate data. And using all the appropriate metadata (including date) would give the same number every time. But somehow, the algorithm would have to never run after the current date, so that potential plagiarists could not figure out what the hash should be for a date previous to the date you published it. That idea needs work, but I feel like maybe it could work out, probably as a separate service. Wouldn't it be cool?

data/bin/mint

@@ -0,0 +1,42 @@
+#!/usr/bin/env ruby
+# A script for harnessing Mint at the commandline
+
+$:.unshift File.join(File.dirname(File.readlink(__FILE__)), '..', 'lib')
+
+require 'rubygems'
+require 'mint'
+require 'optparse'
+
+def usage
+  puts "You're doing it wrong."
+end
+
+unless ARGV[0]
+  usage
+  return
+end
+
+include Mint
+
+module CommandLine
+  module DocumentContext
+    def mint_document(doc)
+      document = Document.new doc, :template => 'normal',
+        :style_destination => 'styles'
+      document.mint
+    end
+  end
+    
+  module ProjectContext
+    def init(dir, opts={})
+      dir = Pathname.new dir
+      if config = (dir + 'config.yaml').exists?
+        proj = Project.new(dir, YAML.load_file(config))
+      else
+        proj = Project.new(dir)
+      end
+    end
+  end
+end
+
+CommandLine::DocumentContext.mint_document ARGV[0]

data/lib/mint.rb

@@ -0,0 +1,433 @@
+require 'pathname'
+require 'fileutils'
+require 'tilt'
+require 'haml'
+require 'rdiscount'
+
+require 'helpers'
+
+module Mint
+  VERSION = '0.1'
+  
+  # Default paths where Mint looks for styles and layouts, in this order
+  $path = [
+    Pathname.new('.mint'),                    # 1. Project-defined
+    Pathname.new(ENV['HOME']) + '.mint',      # 2. User-defined
+    Pathname.new('/usr') + 'share' + 'mint',  # 3. System-defined
+    Pathname.new(__FILE__).dirname + '..'     # 4. Gemfile-defined
+  ].collect! {|p| p.expand_path }
+  
+  # Directories within the Mint path
+  $default_directories = {
+    :templates => 'templates'
+  }
+  
+  # Files within a Mint Project
+  $default_files = {
+    :config => 'config.yaml'
+  }
+  
+  # Registered HTML and CSS formats, for source -> destination
+  # name guessing/conversion
+  $html_formats = ['.haml', '.erb', '.md']
+  $css_formats = ['.sass', '.scss', '.less']
+  $source_formats = $html_formats + $css_formats
+
+  # Default options, where nil acts as described in the specification
+  # Namely, a nil root or destination or style/layout template will
+  # not be used, and a nil name will prompt Mint to guess an appropriate
+  # name based on your source files
+  $default_opts = { 
+    :template => 'default', # this is a new feature I need to test
+    # :layout => 'default',
+    # :style => 'default',
+    :root => nil,
+    :destination => nil,
+    :style_destination => nil,
+    :name => nil,
+    :style_name => nil
+  }
+
+  class Resource
+    attr_accessor :type, :source, :destination, :name
+    
+    def initialize(source, opts={}, &block)
+      # A nil stylesheet or layout should not be rendered, so
+      # we'll return nil here
+      return nil unless source
+
+      # If there is a source, we initialize it right away as a
+      # Pathname, so we can use methods like @source.basename
+      @source = Pathname.new source
+
+      # Load in opts and change nil values to the assumptions
+      # described in the Mint README.
+      @opts = opts
+      
+      # If there is no destination value, ignore it
+      @opts[:destination] ||= String.new
+      
+      # For a nil name, guess based on source
+      @opts[:name] ||= Resource.guess_from(@source.basename.to_s)
+      
+      # Initialize resource values based on normalized, robust
+      # opts. For raw resources (i.e., not for Documents), the destination
+      # and source are both resolved relative to the current working
+      # directory. This only really matters if you are initializing Layouts
+      # or Styles on your own instead of via a Document. If you're using
+      # a Document, all destination paths are resolved relative to the
+      # Document root, which defaults to the content's source directory.
+      @destination = Pathname.new @opts[:destination]
+      @name = @opts[:name]     
+      @template = Resource.template @source
+      
+      # You can use a block to instantiate a Resource. Any values you set
+      # in this block will override all other values.
+      if block_given?
+        yield self
+      end
+    end
+    
+    def equals?(other)
+      destination + name == other.destination + other.name
+    end
+    
+    alias_method :==, :equals?
+    
+    # A convenience method for supplying and selecting configuration
+    # options. If supplied with an array of possible values, will return
+    # the first non-nil value. If the first non-nil value responds to
+    # `call`, will call that function and return its value.
+    def config_with(config)
+      (c = config.compact[0]).respond_to?(:call) ? c.call : c
+    end
+    
+    # Renders the current resource to a string, returning that string
+    # and not outputting to any file. Can operate within the context of
+    # an Object, whose methods can be called from within the template.
+    # Other arguments can be passed along to the template compiler. (For
+    # example, to output HAML as HTML5, pass the option `:format =>
+    # :html5`. See the Tilt TEMPLATES.md file for more information.)
+    def render(context=Object.new, args={})
+      @template.render context, args
+    end
+    
+    # Guesses an appropriate name for the Resource output file based on
+    # its source file's base name. Will convert registered HTML template
+    # extensions to '.html' and CSS template extensions to '.css'.
+    def self.guess_from(name)
+      css, html = $css_formats.join('|'), $html_formats.join('|')
+      name.gsub(/#{css}/, '.css').gsub(/#{html}/, '.html')
+    end
+    
+    # Transforms a path into a template that will render the file specified
+    # at that path. Currently uses Tilt, so any valid Tilt source file
+    # is valid here.
+    def self.template(path)
+      Tilt.new path
+    end
+  end
+  
+  # Layout describes a resource whose type is `:layout`. Beyond its type,
+  # it is a simple resource. However, its type helps decide which template
+  # file to use when a template name is specified. A Layout is best managed
+  # by a Document.
+  class Layout < Resource
+    def initialize(source, args={})
+      @type = :layout
+      super
+    end
+  end
+  
+  # Style describes a resource whose type is `:style`. Beyond its type,
+  # it is a simple resource. However, its type helps decide which template
+  # file to use when a template name is specified. A Style is best managed
+  # by a Document.
+  class Style < Resource
+    def initialize(source, args={})
+      @type = :style
+      super
+    end  
+  end
+  
+  # Document is a workhorse of the Mint library. It extends Resource
+  # to include helpful variables like `root`, which will be the context
+  # for all the Resources it contains. A Document's source is its content
+  # file, from which it can derive a root directory, an output name, and
+  # destination directories. A Document has one Style and one Layout, which
+  # it initializes on creation. Default and optional Styles and Layouts are
+  # included with Mint. You can add more templates to the Mint path
+  # for even more choices.
+  class Document < Resource
+    attr_accessor :root, :layout, :style, :content
+    
+    def initialize(source, opts={}, &block)      
+      # Initialize opts to the default opts, replacing them with user-
+      # supplied opts where possible.
+      @opts = $default_opts.merge opts
+      
+      # Invoke the parent class initializer, which sets the source,
+      # destination, name, template (content), and basic options.
+      super(source, @opts)
+      
+      # Add in Doc-specific opts and change nil values to the
+      # assumptions described in the Mint README.
+      @opts[:root] ||= @source.dirname
+      
+      # If a template name is given, it overrides style and layout
+      # names or files, per the Mint README.
+      if templ = @opts[:template]
+        @opts[:layout], @opts[:style] = templ, templ
+      end
+      
+      @opts[:style_destination] ||= String.new
+
+      style_opts = {
+        :destination => @destination + @opts[:style_destination],
+        :name => @opts[:style_name]
+      }
+      
+      # Initialize resource values based on normalized, robust opts. For
+      # Documents, the destination is resolved relative to the document
+      # root. The root and source paths are both resolved relative to the 
+      # current working directory whenever this instantiation method
+      # is called.
+      @type = :document
+      @root = Pathname.new(@opts[:root]).expand_path
+      
+      @content = Resource.template(@source).render
+      @layout = choose_template(@opts[:layout], :layout)
+      @style = choose_template(@opts[:style], :style, style_opts)
+      
+      # Be careful not to modify this code such that you can change the
+      # current working directory before the source directory is normalized.
+      # expand_path is always called relative to the *current* working
+      # directory, not the initial one.
+      @source = normalize_path(@source) # becomes relative here
+      
+      # You can use a block to instantiate a Document. Any values you set
+      # in this block will override all other values.
+      if block_given?
+        yield self
+        mint
+      end
+    end
+    
+    # Returns the relative path to dir1 from dir2, which defaults to the
+    # Document root.
+    def normalize_path(dir1, dir2=root)
+      Document.normalize_path(dir1, dir2)
+    end
+    
+    # Returns the relative path to dir1 from dir2.
+    def self.normalize_path(dir1, dir2)
+      path = case dir1
+        when String
+          Pathname.new dir1
+        when Pathname
+          dir1
+        end
+
+      path.expand_path.relative_path_from dir2
+    end
+    
+    # Decides whether the template specified by `name_or_file` is a real
+    # file or the name of a template. If it is a real file, Mint will
+    # return a template using that file. Otherwise, Mint will look for a
+    # template with that name in the Mint path. The `layout_or_style`
+    # argument indicates whether the template we are looking for is
+    # a layout or a style and will affect which type of template is returned
+    # for a given template name. For example, `choose_template('normal',
+    # :layout)` might return a Layout template referring to the file 
+    # ~/.mint/templates/normal/layout.haml. Changing the second argument
+    # to :style would return a Style template whose source file is
+    # ~/.mint/templates/normal/style.sass.
+    def choose_template(name_or_file, layout_or_style=:layout, opts={})
+      template = File.file?(name_or_file) ? Pathname.new(name_or_file) :
+        find_template(name_or_file, layout_or_style)
+        
+      Mint.const_get(layout_or_style.to_s.capitalize).new(template, opts)
+    end
+    
+    # Finds a template named `name` in the Mint path. If `layout_or_style`
+    # is :layout, will look for `MINT_PATH/templates/layout.*`. If it is
+    # :style, will look for `MINT_PATH/templates/TEMPLATE_NAME/style.*`.
+    # Will reject raw HTML and CSS, which are currently not compatible
+    # with Tilt, the rendering interface that Mint uses. (There are plans
+    # to support these files in the future.) Mint assumes that a named
+    # template will hold only one layout and one style template. It does 
+    # not know how to decide between style.sass and style.less, for 
+    # example. For predictable results, only include one template file
+    # called `layout.*` in the TEMPLATE_NAME directory. If you do want
+    # several style files in the same template directory, you will want 
+    # to refer to the style file by its path and not by its template name.
+    # Will return nil if the named template is not in the Mint path.
+    def find_template(name, layout_or_style)
+      file = nil
+      
+      $path.each do |directory|
+        templates_dir = directory + $default_directories[:templates]
+        query = templates_dir + name + layout_or_style.to_s
+        
+        if templates_dir.exist?
+          # Mint looks for any
+          results = Pathname.glob "#{query}.*" 
+        
+          # Will only allow files ending in extensions that Tilt can
+          # handle. They are working to add raw HTML and CSS support, but 
+          # it is not yet implemented.
+          results.reject {|r| r.to_s !~ /#{$source_formats.join('|')}/}
+        
+          if results.length > 0
+            # Will return the first match found. See the `find_template`
+            # description for a discussion of when you should and should
+            # not rely on this method.
+            file = results[0]
+            break
+          end
+        end
+      end
+      
+      file
+    end
+    
+    # A Document renders itself (its content) in the context of its layout.
+    # This differs from raw Resources, which render themselves in the
+    # context of `Object.new`
+    def render(args={})
+      layout.render self, args
+    end
+    
+    # Renders and writes to file all Resources described by a Document.
+    # Specifically: it renders itself (inside of its own Layout) and then
+    # renders its Style. This method will overwrite any existing content
+    # in a Document's destination files. The `render_style?` option
+    # provides an easy way to stop Mint from rendering a style, even
+    # if the Document's style is not nil. This makes it possible to
+    # associate a style with a Document (a style that can be called
+    # from layouts via `stylesheet`) without regenerating that
+    # stylesheet every time Mint runs.
+    def mint(render_style?=true)
+      
+      resources = [self]
+      resources << style if render_style?
+    
+      resources.compact.each do |r|
+        dest = @root + r.destination + r.name
+        
+        # Kernel.puts <<-HERE
+        #   Source: #{@root + r.source}
+        #   Destination: #{dest}
+        # HERE
+        
+        # Create any directories in the destination path that don't exist.
+        FileUtils.mkdir_p dest.dirname
+        
+        # Render the resource to its destination file, overwriting any
+        # existing content.
+        dest.open 'w+' do |file|
+          file << r.render
+        end
+      end
+    end
+    
+    # Convenience methods for views
+    
+    # Returns a relative path from the Document to its stylesheet. Can
+    # be called directly from inside a Layout template.
+    def stylesheet
+      normalize_path(@root + style.destination, 
+        @root + @destination) + 
+        style.name.to_s
+    end
+  end
+  
+  $project_default_opts = {}
+  
+  class ProjectDocument < Document
+    attr_accessor :changed?
+  end
+  
+  class Project
+    attr_accessor :root, :documents, :layout, :style, :config
+    
+    def initialize(root, opts={})
+      @opts = opts
+      @opts = $project_default_opts.merge opts
+      
+      if templ = @opts[:template]
+        @opts[:layout], @opts[:style] = templ, templ
+      end
+      
+      @root = root
+      @documents = Array.new
+      @style = @opts[:style]
+      @layout = @opts[:layout]
+    end
+    
+    def mint
+      @documents.each_index do |i|
+        render_style? = (i == 0)
+        @documents[i].mint(render_style?)
+      end
+    end
+    
+    def change_status(document, new_status)
+    end
+    
+    def status
+    end
+    
+    def add(document)
+      doc = Document.new
+      doc.layout = @layout
+      doc.style = @style
+      doc.root = @root
+    
+      @documents << doc
+    end
+    
+    alias_method :<<, :add
+    
+    def remove(document)
+      @documents.delete document
+    end
+    
+    def list
+    end
+    
+    def edit(file_or_name, type=:layout)
+      
+      
+      if editor = ENV['EDITOR']      
+        `#{editor} `
+      end
+    end
+    
+    def watch
+      require 'fssm'
+      
+      FSSM.monitor do
+        path root do
+          glob '*'
+
+          update {|base, relative|}
+          delete {|base, relative|}
+          create {|base, relative|}
+        end
+      end
+
+      path 'templates/**/*' do
+        update { |base, relative| update(relative) }
+        delete { |base, relative| update(relative) }
+        create { |base, relative| update(relative) }
+      end
+    end
+    
+    def update(relative)
+      puts ">>> Change Detected to: #{relative} <<<"
+
+      puts '>>> Update Complete <<<'
+    end
+  end
+end

data/templates/default/layout.haml

@@ -0,0 +1,7 @@
+!!!
+%html
+  %head
+    %link{ :rel => 'stylesheet', :href => stylesheet }
+    
+  %body
+    #container= content

data/templates/default/style.sass

@@ -0,0 +1,21 @@
+body
+  font-family: 'Hoefler Text', Georgia, Garamond, serif
+
+code
+  font-family: Monaco, 'Lucida Console', Consolas, Monotype, mono
+
+@media screen
+  body
+    font-size: 16px
+  
+  #container
+    display: block
+    margin: 1em auto
+    
+@media print
+  body
+    font-size: 12pt
+    margin: 1in 1.25in
+    
+  img
+    display: block

metadata

@@ -0,0 +1,72 @@
+--- !ruby/object:Gem::Specification 
+name: mint
+version: !ruby/object:Gem::Version 
+  hash: 9
+  prerelease: false
+  segments: 
+  - 0
+  - 1
+  version: "0.1"
+platform: ruby
+authors: 
+- David Jacobs
+autorequire: 
+bindir: bin
+cert_chain: []
+
+date: 2010-06-28 00:00:00 -04:00
+default_executable: 
+dependencies: []
+
+description: 
+email: david@allthingsprogress.com
+executables: 
+- mint
+extensions: []
+
+extra_rdoc_files: []
+
+files: 
+- README.md
+- bin/mint
+- lib/mint.rb
+- templates/default/layout.haml
+- templates/default/style.sass
+has_rdoc: true
+homepage: http://github.com/davejacobs/mint/
+licenses: []
+
+post_install_message: 
+rdoc_options: []
+
+require_paths: 
+- lib
+required_ruby_version: !ruby/object:Gem::Requirement 
+  none: false
+  requirements: 
+  - - ">="
+    - !ruby/object:Gem::Version 
+      hash: 3
+      segments: 
+      - 0
+      version: "0"
+required_rubygems_version: !ruby/object:Gem::Requirement 
+  none: false
+  requirements: 
+  - - ">="
+    - !ruby/object:Gem::Version 
+      hash: 23
+      segments: 
+      - 1
+      - 3
+      - 6
+      version: 1.3.6
+requirements: []
+
+rubyforge_project: 
+rubygems_version: 1.3.7
+signing_key: 
+specification_version: 3
+summary: Clean, simple library for maintaining and styling documents without a word processor
+test_files: []
+