First Crack Release Notes, September 2019

As I rolled into the last week of September, I started thinking about this post and how I have done almost nothing for it. I put a lot of work into some major performance wins last month, but lost almost all that momentum when I decided to write my own Instapaper-like read later service in September. It needs some more work before I release it, but I will. I did get a couple things done, though, even if I did forget to post this until the first week of October had already passed; I did not neglect First Crack entirely.

September Activity #

Most of my work in September involved refactoring and code documentation — the un-sexy but necessary work that makes for a better project in the long run. Outside of that, I also took some time to enable First Crack to handle articles written in raw HTML. This need came about as I wrote Building a Syllable Dictionary in Python, which made heavy use of long HTML blocks for static code snippets with syntax highlighting. Most websites use Javascript for this, but thanks to hilite.me, I avoided that. After the title block, use <html> to keep First Crack from parsing the rest of the article as Markdown.

October Plan #

Going forward, I plan to focus on these areas in October, 2019. I carried most of these over from last month’s update.

Re-Implement "Pretty Print" #

I would still like to re-implement the “pretty print” feature now that First Crack uses a stateful Markdown parser. Low priority, but something I want to get done nonetheless.

Release Markdown Parser #

I still want to release my Markdown parser as its own project. I still have some bugs to work out, though, I want to go public with greater coverage of the spec, and I would like to add the ability to parse multi-line strings and entire files at once.

Publish Implementation of Markdown Spec #

I still want to outline the peculiarities of my implementation of the Markdown spec. This would cover weird edge cases for the most part, but documenting these shortfalls would still have value so that those who use my engine will have some sort of explanation for why their article looks weird, and so that I may one day fix them. I made some progress here this month, but not enough for a finished product.

Improve Documentation #

I did some work on the documentation this month, but as always, I could do more. Again, a few of the ways I think I can improve the README in particular:

As always, I look forward to the work ahead.

Permalink.