When I got my new Mac, Sublime Text started occasionally crashing on me. And, while I do like Sublime Text more than Emacs for non-programming typing, I wasn’t in love with Sublime Text, either: it still feels like a cross-platform editor that wasn’t focused on presenting a clean interface. Also, at about the same time, I was thinking about moving my blog post writing outside of the WordPress web interface: to something outside of a web browser with a nice clean interface. (Not that WordPress’s focus mode isn’t good for that latter criterion!)

So I poked around a bit, looking at macOS-native editors that were focused more on writing than on programming. I wasn’t sure I was going to use it exclusively on prose, I was thinking I might use it to maintain the various lists and what not that I have as part of my GTD setup, but blog post writing was the main initial use case.

 

The editors that I came across supported Markdown. Which makes sense: I was looking at plain text editors, but that doesn’t completely remove the desire for styling and links and what not, and Markdown is the consensus choice there. But it was a change of pace, since, for this blog, I’ve actually been writing the little bits of the HTML in the posts (links, etc.) by hand instead of using WordPress’s rich editor; which is fine, it’s not particularly tedious.

But Markdown is fine too; and, actually, if my goal is to have a clean interface, than Markdown is better than HTML. The one thing that gave me pause there is that I use <cite> tags for book names and the like; the truth is, though, that while I was convinced by the arguments for semantic tags when I first saw them decades ago, in practice I’ve never wanted to style <cite> differently from <em> and I’ve never written code that goes through a document and pulls out the <cite> tags for bibliographic purposes or anything. So, ultimately, I don’t see HTML as about semantics any more; I’ll live with putting underscores around book names. (Using asterisks for italics still feels weird to me, though: asterisks should be for bold!)

 

The first editor I tried was Ulysses. It actually looked a little more ambitious than I necessarily wanted: it looks like it’s designed to let you write an entire book with it if you want. And I wasn’t sure if I wanted something with a multi-pane model, though given that you can easily hide the panes other than the one you’re writing in, that wasn’t really an active strike against it.

When I gave Ulysses a try, I enjoyed it: composing was pleasant, exporting to HTML so I could post to my blog wasn’t too bad. The main downside was that I couldn’t type raw HTML; that was while I was still unsure what to do about <cite> tags, but I got over that, but a little more problematic was that I’m used to having a paragraph with only &nbsp; in it to create an extra blank line, and I couldn’t figure out how to do that in Ulysses.

Still, seemed good enough; I figured I’d try other options, but if Ulysses was where I ended up, then great. Except that then I used it to edit my GTD reference file; and, when I looked at the file through another method, I found that it had moved all of my links that had just been pasted in raw to the end of the file (using one form of the Markdown link syntax), even in parts of the file that I hadn’t touched!

And that really wasn’t cool – partly because I don’t like that sort of messing around behind my back, but also partly because, ultimately, I want a plain text editor rather than a rich text editor. And, philosophically, it seems like Ulysses is a rich text editor: it uses Markdown as a representation format, but it doesn’t want you to care about that representation. Which could actually be fine for blog posts, but does limit the contexts in which I’d be willing to use the editor.

 

Next on my list to try was Byword. It’s simpler than Ulysses: no three panes, no focus on projects, it has you editing one file at a time.

And, it turns out, it’s much happier than Ulysses to accept whatever you type. If you type HTML tags or entities, it’ll pass them through unscathed during HTML conversion; and if I open a file with a naked link in it, it leaves the link there unscathed instead of moving it around.

Byword claims to be able to export to WordPress installations; when I was first looking at that, that was a paid extension to the app, but they made it free a couple of days later. Which is good, because it doesn’t work when publishing to my blog; I’d actually e-mailed Byword support when it was a paid extension to confirm that it should work for self-hosted blogs, but it doesn’t work for me. No idea what’s going on there; but the amount of work that would be saved by that is trivial, it’s very easy to copy and paste the HTML.

 

So I stopped my search there, and I’ve written my last ten or so blog posts in Byword. And it’s been nice! Honestly, not that much nicer than just writing in the WordPress editor directly, but still: I do somewhat prefer typing in a separate app, in a window with basically my words and nothing else.

Arguably more importantly: from a philosophical point of view, I’ve now switched to Markup as the way to go, instead of HTML or ad-hoc plain text. Slack and Github had been moving me that way anyways, good to have that formalized.

Post Revisions:

This post has not been revised since publication.