First Crack Release Notes, May 2020

I have wanted to add this to First Crack for a while now, and this month, I finally did it: First Crack now supports post categories.

As a brief refresher, First Crack supports two article types: linkposts, which use a link as their title to refer readers elsewhere, and original articles, which do not. When I copy a new post into the deployment folder, First Crack detects the post type and builds a header based on it, like the one below:

Type: linkpost Title: How apocalyptic is now? Link: Pubdate: 2020/05/20 15:45:59 Category: Uncategorized Author: Zac Szewczyk

For original articles, the header structure remains the same but some of the values change:

Type: original Title: The Best of the Best Link: the-best-of-the-best.html Pubdate: 2020/05/26 08:27:25 Category: Uncategorized Author: Zac Szewczyk

First Crack now stamps each post with the category on line five; clicking that link will take you to an index page with all other articles in that category sorted by time. I need to spend some time re-categorizing my posts, but you can test this new feature out now by clicking the “Development” link underneath the title.

Feature Roadmap #

Along with general maintenance and my constant pursuit of optimization, I also want to get these things done.

Add Syntax Highlighting to Markdown Parser #

Now that First Crack wraps code blocks in <div> instead of <pre> elements, I can add automatic syntax highlighting. Ben Kuhn described an interesting, minimalist approach back in 2018; I plan to do something along these lines.

Release Markdown Parser #

I want to release my Markdown parser as its own project. I fixed a few bugs during the rewrite, but I still have some others to work out. At the least, I want to go public with greater coverage of the spec, and with the ability to handle multi-line strings and entire files at once. My main goal is to design a performant Markdown parser and then write an efficient implementation of it. Several people have already done some interesting work in this space. At present, it implements the subset of the spec I use on a regular basis, and handles files one line at a time.

Publish Implementation of Markdown Spec #

Along with the release of my Markdown parser, I will need to outline the peculiarities of my implementation. Parity with John Gruber’s spec would make sense, or something like GitHub Flavored Markdown which has much more detailed documentation, so I may go this route; if not, I will need to produce my own documentation. This would cover weird edge cases for the most part, but it would also give those who use my engine have some sort of explanation for why their article looks weird. In brief, my argument against going with a standard comes down to the fact that I have little use for most of those features and edge use cases. Once this becomes its own project, though, that others may use, this argument gets shakier. I will have to spend some time thinking about this before I move forward.

Improve Documentation #

A few of the ways I think I can improve the README in particular:

As always, I look forward to the work ahead.