So, now it uses git dates. This introduces the possibility for two articles to have exactly the same creation date. So, I've changed tagindex to sort first on creation date, then on filename. That way we end up with a consistent and reliable ordering when two or more mime files are added in the same commit.
I realized that the ID is the filename I chose. The only reason I had ID in GitSite was because the filenames were the title. Here the title is in the file, and the filename is the unique ID. So, if I decide I want an ID separate from this later I can add it back in. If not, then I'm glad it's gone.
At this time it just includes all of the articles into the page. It lists them in reverse order of creation. It would be trivial to limit it to the most recent N, but I really don't care enough right now to do that. Also, then it's like "Well, do I do paging for the rest?" I figure I'll add that feature when I have an issue with too many articles. Until then, I don't care. It also has the entire article contents. I may make a "snippet" file at some point which is like converted but contains only the first bit of a document. Either way, I don't now. I could also change it so that it always shows all articles, but only shows contents (or snippets) for the first N. I'll figure that out when it's important.
So, now it extracts the Content-Type and builds a type-converter for that type. It defaults to text/plain. I've written a text/plain, which just puts <pre> before the body and </pre> after the body. I've also added a text/html which does nothing. Feasibly it could do cleanup, or sanitizing, or anything, really. As a test for that one, I changed t4.mime to be html. So. Yeah.
More useless tests. I built a few of these up as I made sure things like tagindex and all and stuff were behaving properly. Things like rebuilding the index if the tags a file's in changes, or rebuilding the index if I add a new file, but not rebuilding if I don't do any of those things. It also gives more things to test next and prev with, and anything more stressful that 2 files is a better test.
So, now my html files have a link to prev, if there is one, and next if there is one. The test.tagtemplate does not, which I'm fine with for now. It's another one of the ways it's different.
So, now most things rely on a file called tagindex. It's generated from .augmented files and is rebuilt if any of the mime files change, or if a new one is added or one is removed. It generates a file that looks like: tag1 file1 tag2 file1 tag1 file2 tag3 file2 tag4 file2 tag2 file3 Or whatever. So, then all.do just uses that index to figure out it should build: file1.tag1.html file1.tag2.html file2.tag1.html ... That makes me much happier, because it cut down on the amount of knowledge all.do needed. It used to search through mime files to Tag: and stuff. Now it just generates the tagindex and says "Ok, I'll build these" The per-tag tagindex is removed in this iteration. It's now become (grep '^tag ' < tagindex | cut -d ' ' -f2-) I could have made a tagindex for each tag that just did that, but I decided that was overkill. So, default.html.do was changed to use that rather than $tag.tagindex It got a little uglier... because I end up doing the above 3 times. I might "cache" it into a variable later. Deploy didn't change a lot. I just realized, as I was looking into why it needed to know which tags a file had, that I wrote it badly. I was grepping through mime files to try and figure out some list of all tags, so I could make those directories. Then I proceded to iterate over all html files and extracted the tag from the filename as God (I) intended. So I just took out the part above and put a (mkdir -p) in the iteration part of the loop, right before the part where I use that directory. So, now it doesn't require knowledge of tags at all, it just puts files of the format title.tag.html into tag/title.html. This makes me much happier. So, I think this was a good step.
Currently the template doesn't use them. I've picked Next-Link and Previous-Link which are terrible. Maybe I'll pick better ones later. It builds a tag-index for each tag. This will likely be used later when constructing index files and feeds.
Based off what singpolyma did, changed it so each step only has one extension. Cleaner, more seperation. Good. Not great, but good. Also, the html file now is an html file because I changed where in the path the file is given the html extension. What was tag is now html, what was html is now "converted"