It started with a blog post by Ian Lurie in September 2016. At the time I had a workflow of feedly -> pocket -> evernote. That post made it to evernote with a tag to revisit.
Suddenly references to Markdown were everywhere. Conferences, podcasts, and of course readme.md on github. After a few frustrating mis-steps with using nano to edit Markdown, I resigned to editing readme files in the browser instead of locally.
My second false start with Markdown was in June 2017. I got really excited about using Jupyter instead of powerpoint. Neatly formatted and runable code in my slides? Sign me up! A few trials and odd line breaks had me back to boring old powerpoint. Then a lightning talk at All Things Open 2017 renewed my interest. Quickly followed by another timely blog post by Ian Lurie. His post on how to set up Atom for Markdown was the tipping point.
During my annual clean out of evernote, I came across that initial post that started this whole thing, I was just too busy to think about Markdown.
Here it is January, I am not taking a class this semester, holidays are over, and the weather is shockingly cold. Finally time to take the plunge into Markdown. I set up a github pages blog using Jekyll to give me a real reason to use Markdown. This is my second post written in Atom. Having an environment that I know and trust has been the friction reducer I needed.
I added linter-markdown to Atom to avoid making some silly errors.
Kramdown Quick Reference is a nice cheat sheet to less used markup and notations. Kramdown has some additional features that are not in GFM.
Markdownify for a lightweight alternative to Atom. Atom is more code editor than a word processor. Markdownify is the middle ground between Atom and focuswriter.