My Writing Tools

December 2020 kicked off a period of real creativity for me and is still going strong six months later.

I’m programming more than I have in over a decade.

I joined a Guitar Circle and am learning to play in New Standard Tuning - with a pick no less.

And as always, I’m using writing as a way to increase my understanding and insight.

From a tools perspective, I feel like I’ve come full circle. I decided to catalog my journey here, mainly for the perspective I get out of writing stuff down. What can I say, I’m a tools junkie.

TL;DR

I now live happily in VS Code, writing Rust and/or Markdown for pretty much everything. It’s pretty sweet. The rest of this page is all historical.

Editing Text

My first real computer was a Macintosh 512K, and I had evolved to a Max SE/30. The first text editor I fell in love with was MPW Shell. I was doing freelance Mac programming in C++ and HyperCard to pay the bills, and this is where I started. I loved the way the shell and editor integrated with one another - select text in any window and hit Cmd-Enter. It was mind-blowing!

When I hit grad school, I started using NeXTcubes followed shortly by Sun workstations, so I picked up GNU Emacs as my primary editor, as it was everywhere I needed to be. Note that I learned Objective-C before learning C++, which may explain why I don’t hate Objective-C

I lived in emacs throughout grad school and for about a decade afterwards. It was my source code editor, my shell, and my email system. I really loved it.

Any time I found myself doing things outside of emacs, I had the feeling that I wasn’t quite smart enough to do the task properly or efficiently. More on this later.

I stayed with emacs after I started working at Microsoft, to the point where I gave a keynote at the 2003 Microsoft’s Professional Developer’s Conference (the //build of the 1990’s and 2000’s) using only emacs. No PowerPoint. No Visual Studio).

When Visual Studio 2005 (a.k.a., Whidbey) was in development, some people on the team really wanted me to dogfood and give my direct feedback, so I did put emacs on the shelf and made the switch. The tool quickly got to be good enough to become my daily driver, and I used Visual Studio until about 2007.

By 2007, I was on a project called Oslo, and we were building a new text editor (Intellipad/ipad.exe) and IDE (Quadrant) based on a fork of the then in-development rewrite of the VS editor. Naturally, I switched from VS to the Oslo tools and lived in them until the project’s demise in 2010.

After that, I reverted back to emacs, but had long since lost my precious ~/.emacs file). Without those thousands of lines of elisp, I was starting over and never really re-bonded with it.

Eventually, I switched to VS Code shortly after it was released. I haven’t looked back since.

Text Editor Start Date End Date
Macintosh Programmer’s Workbench ~1986 1990
GNU Emacs 1988 2004
Visual Studio 2005/2008 2004 2007
Microsoft Intellipad/Quadrant (beta) 2007 2010
GNU Emacs 2010 2015
VS Code 2015 -

I’m really hoping VS Code is the last editor I need to adapt to - both because I love it, and honestly, the switching cost is pretty high for me. That said, when EMG and 6dof tracking become competitive with keyboards for text entry, I’m open to switching editors if absolutely needed.

Creating and Publishing Prose

Earlier I mentioned that I felt slightly inadequate when I had to leave emacs to get things done. The most conspicuous place where I failed to live up to the ideals of emacs usage was when it came to authoring documents and presentations.

Being a Mac person even through grad school, I couldn’t fathom having to use a compiler and asynchronous previewer to work on papers (LaTeX) or slides (SliTeX). I managed to get a few academic papers authored in FrameMaker published, but I was definitely swimming upstream. I was young and foolish and in retrospect, I should have embraced the *TeX lifestyle, which is actually pretty close to how I work now.

Shortly after leaving grad school, I switched to publishing books, articles, and columns. I found that Microsoft Word was good enough, and it became my primary way to get paragraphs out of my head and into digital storage. The publication part was pretty straightforward. I’d email Word documents to my editor (the human kind), and they’d send back either post-layout PDFs (MSJ and MSDN), proofs and F&G’s(Addison Wesley), or plain-old-text comments (C++ Report).

I pretty much stopped the book/article/column routine when I started working at Microsoft in 2002. My day job at the time was working on Microsoft’s SOAP implementation, which grew out of an early collaboration with Dave Winer, Mohsen Agsen, and Bob Atkinson.

Dave also was an early pioneer in RSS and blogging, both of which were heating up at the time.

I got interested in how RSS was building momentum (while SOAP well…wasn’t). I also missed writing, so I decided to stand up a blog to try to internalize what was going on. My dear friend Sara Williams (nee Spalding) from the .NET Framework team let me set up a static directory on the now defunct gotdotnet.com IIS server, and presto, Microsoft had it’s first public blog.

That first blog was authored as a ginormous XML file, and the HTML, RSS, and eventually AtomPub projections were done in XSLT. IIRC, “publishing” was just updating my content.xml file over SMB, and the XSLT’s ran either as an IIS filter or via the xml-stylesheet processing instruction. I really loved that environment - it was simple and immediate.

When PluralSight got started by a few friends/former coworkers, I moved my blog to their site using an off-the-shelf blog engine (DotText). The writing experience was meh but I was happy to be working with Aaron, Keith, and Fritz so it was all good.

About a year ago, I started writing primarily in Markdown using VS Code. The syntax is easy on the eye and my fingers, and I’m hoping this is the last format I need to master.

In terms of publishing, I’m using jekyll to generate this site, which is backed by a simple github repo. It’s quite sweet actually.

Document Format Process Start Date End Date
FrameMaker Submit via snail-mail or PDF’s through FTP 1987 1992
Microsoft Word Email to editor/publisher 1992 2003
XML Edit in Emacs over SMB, publish via IIS and XSLT 2003 2004
The other .NET-based engine (not DasBlog) Browser-based editor 2004 ~2008
Markdown Edit against Github et al, publish via Jekyll or project-specific doc toolchains 2017 -

Markdown is obviously here to stay - I’m hoping I can avoid RST but who knows. I’m already finding myself working in non-Git repos again, so I’ve resigned myself to not caring on this one. Jekyll is new (and I’m new to it), but my needs are modest.

Creating and Publishing Slides

I gave my very first presentation in 1986 (my first year in grad school) as part of a funding pitch our group was making.

I wrote it on my Mac in Dave Winer’s More, and printed it out on transparency film (what Intel people refer to as foils). Horrible talk, horrible tech, but More was pretty nice.

Like the rest of the world, I adopted PowerPoint and wrote way too many conference talks and courses in it.

Around the time I got to Microsoft, I had largely moved to giving talks in text editors, which is still how I like to work.

Recently, I discovered Marp, which allows me to author in Markdown, and present in formatted form from a preview window inside of VS Code. Yes, this too is pretty sweet.

Presentation Format Process Start Date End Date
More Print transparencies 1988 1992
Microsoft PowerPoint Projectors using VGA/DP/HDMI 1992 2003
Ad hoc plain text and code Projectors using VGA/DP/HDMI or Miracast (when it worked) 2003 2020
Markdown Edit against Github et al, present via Marp preview over Microsoft Teams 2020 2020
Markdown Edit against Github et al, present via Marp preview over the rest of the world’s video conferencing systems 2021 -

Again, I think Markdown is here to stay, and again, Marp meets my modest needs.

I will say that I miss the ubiquity of Microsoft Teams since I’ve left MS. I now find myself using 5 different VC solutions in a given week - none of which are Teams. Sigh…

Creating and Publishing Music Manuscripts

I haven’t composed new music for a very long time, but I love transcribing music, primarily to really understand a how a piece of music holds together.

For many years, I would do the annual “which do I dislike the least - Finale or Sebelius” test during the holidays. Until very recently, Finale came out ahead, primarily due to the fact that it supported Chord Symbol playback, which comes in really handy for lead sheets.

A few months before COVID hit, my piano teacher turned me on to Musescore, which has my pet Finale feature AND is a much better input medium. Finale does a better job at printing, but not enough to warrant me continuing to use it.

In 2020, my annual test took a very different form. I spent my holiday break learning Rust by writing a domain specific langauge and compiler for music notation. The upside of this approach is that I can use VS Code as my authoring tool (which is ideal for me), and I can write backends to whatever I need to publish to (primarily MusicXML, ultimate-guitar.com or iRealPro). Alas, I think it’s going to take the next holiday break before it’s good enough to use as my daily driver.

My Writing Rig

My rig