~kungtotte/dtt

Forgot to track tmpl.nim and made a derp

I thought I was being smart by reading the version tag from
dtt.nimble.

dtt.nimble is not compiled into the binary.

Sometimes being clever is the same thing as being dumb.
Update buildCmd to work with static assets

Now buildCmd will construct and render any markdown files into
templates, but will leave every other kind of file and directory alone
inside /content/ and simply copy them as-is to /output/

This way you can run dtt init, add all your static assets inside
/content/, hit dtt build, and that's that!

No magic, really, just straight-forward file operations.
Lift template rendering out into a proc

This is so I can more easily build the recursive function for walking
through `content_dir` so that static assets get moved over properly.
Add helper proc to load meta-data

buildCmd is already the most complicated procedure in the program,
no sense in cluttering it up more than we have to.
Move template raw strings into a separate file
Load version number from dtt.nimble

Why make it harder on ourselves?
Move meta-data loading out of the loop
Change case of readme file to fix rendering
Add readme.md

Also tweaked .gitignore a bit and removed some useless parts from
the init section of the tool. Why complicate things with css and static
folders when we can just copy things over from content/ at will?
Tweak template to load meta from config.cfg

Also make sure we don't track config.cfg in git, we don't want that.

TODO: Make sure content_license_url is optional
Make buildCmd actually do the thing

(get it? do the thing = dtt) That was my desired goal for this tool.
It should offer zero friction to a straightforward publishing workflow.

This is what it should look like for a new site:

dtt init -> Supply values for things like title, author name, email
write markdown inside ./content/
dtt build
publish ./output/

Tweaking should be easy and simple, it should build a straight up
HTML+CSS site, changing it to use different HTML or CSS should not
require editing a million files or learning a custom DSL.
Add rough blog-post template and partials

Fix the templates so we can write blog posts and have partial
mustache template support for headers and footers.
Add config file support

This seems to be the easiest way to centrally define meta variables
like charset, title, email, author name, etc. instead of forcing them
to edit a template.

For bonus point it could ask for values during `dtt init` so it's
auto-populated with the author's desired values.
Add LICENSE file (GPL 3.0)
Add build command

The meat and potatoes of this tool. You can write the templates and
stuff out by hand if you wanted to, but putting it together and making
an actual page is what dtt is all about after all.

I think I have a good idea about how I want to do this, so let's see
how it works out.

Here's the rough plan:

header.md - special case: will become the header content
footer.md - special case: will become the footer content
nav.md - special case: will become the navigational content
<page>.md - becomes page.html
/posts/<name>.md - automatically indexed as blog posts
Tweak templates and import the libraries we need

I've never worked with mustache before so it's a bit of a learning
curve getting the templates right.
Update gitignore to exclude output dirs
Add 'clean' command

I figured it's easy during development to have something clean out
the output directory and start over, as well as when you're actually
using the tool to make sure you get a fresh build.
Add simple template scaffolding

This seems to be the easiest way to bake it all into one binary
(a project goal).

I'm thinking it writes out the very basics of what you'd want for
a project scaffolding so you can essentially just type some copy and
hit build.
Create initial scaffolding for the tool

This is the very basics of what the tool will eventually do, but
you got to start somewhere.
Next