Regarding my dream Markdown editor

While there was some excitement and hearty agreement with the list of my ideal Markdown text editor features, there was also some criticism. There were some valid points in all of the critiques, and I’d like to address them. I’ll do so by rambling a bit.

First, I think that some critics felt the list was overwhelming, and didn’t really dive in and consider the ramifications (or lack) of the features mentioned. I think the length and detail of the text was misleading when skimmed. The feature set is not as intrusive as it looks at first glance.

There was also a healthy portion of “Markdown is plain text, I want to edit it as plain text.” And that’s fine. If you don’t need anything more than TextEdit or your favorite code editor, then a Markdown editor isn’t really your market anyway. The list–and any debate surrounding it–is for people who use Markdown-specific editors and want to expand on them.

There’s room for those who fall in between, of course, and I understand that anything that makes Markdown editing into a word processor is counterproductive. Markdown is also, however, about convenience. Increasing productivity while writing is my goal, not adding buttons, bloat or new markup features.

My initial list was formulated over several years, but written in about 20 minutes. It was loosely organized and quickly typed. I’ll attempt here to sort things a little better as I expound on my requests. This probably won’t be brief. Apologies in advance¹.

Invisible and unobtrusive

My dream editor’s features are transparent. Byword is a great example of this. You can just edit text in it with nothing standing in your way. However, it has a lot of handy tricks under the surface if you learn how to access them. They’re not blatant; you have to seek them out. Many of the items on my list fall into this category. They’re not attached to standard keyboard motions, so you’d never know they were there.

This is the basis for all of my requests. They are features that should flow with you, not jump out at you.

Keyboard shortcuts.

Having more advanced features assigned to key combinations that you’d never type accidentally does not add friction to standard text editing. It adds power for those who want to use them. There’s no reason, in my mind, not to have non-standard editing features available if they don’t interfere with standard Cocoa text field features.

Many of the items in my list mentioned an unspecified “hotkey” or “keyboard shortcut.” I didn’t assign anything because that isn’t really important at this phase. Developers will eventually work out what’s best, and a standard will evolve. I generally subscribe to the conventions that Allan Odgaard laid out for shortcuts in TextMate bundles. The key combinations I did specify were fairly standard for their behavior in this regard.

Take ⌘↩ for example. I don’t believe there’s any reason in the regular text system to hit Command-Return while typing text. Most people don’t have that in their muscle memory and generally wouldn’t think to hit it, so it’s an easy-to-remember but out-of-the-way shortcut. TextMate users, on the other hand, generally adore the fact that in TextMate this jumps out of the paragraph and starts a new line without breaking the line at your cursor (it’s o in Vim). This is useful, and you don’t have to avoid it if it’s unwelcome; unless you have a valid reason to be hitting , it’s a feature you’ll never notice.

On my own system (using Cocoa keybindings), ⌃⌘←/→ indents and outdents lines, and ⌃⌘↑/↓ moves lines up and down, swapping places with lines above and below. This is another convention borrowed from several places, and I believe it to be relatively standard for this action. I’m completely open to developers making arguments for something else, but again, this is a key combination that is easy to use but not something you’d accidentally trigger. ⌘[/] are also commonly used for indent/outdent. I’m open to anything that meets the criteria.

Automatically inserted text

Some features involve text being inserted as you type, which I think are the features that scare people the most. Rightly so; improperly implemented they’re an annoyance that adds friction to an otherwise very simple process. Properly done, they transparently remove friction and save time.

Features such as list continuation (an asterisk and a space being inserted on a new line when you press return at the end of an existing list item) are already becoming par for the course. List continuation has been around in some editors since I started writing Markdown some years ago. Many implementations of it, though, do annoying things like making you backspace the last list item before pressing Return. That’s a hindrance. I shouldn’t have to remove text I didn’t insert.

The same goes for auto-pairing. A poor implementation of it ends up with me spending more time deleting characters I didn’t want than it saves. It has to be smart enough to know when I actually want a right bracket inserted, and gracious enough to delete the extra character automatically when it’s apparent I didn’t want it. If it can’t do that, I’d rather not have it (selection wrapping, though, I don’t want to be without). Specifications for this behavior were in the original list, but I think that some readers glazed over that part (understandable, but you really should finish reading the post before firing off a Tweet).

Text manipulation

Along the same lines as , using tab to indent a block of text is very useful in Markdown, especially for creating “verbatim” blocks (code/poetry with line breaks respected). It also doesn’t tread all over any standard behavior. If you’d never used such a feature, why would you select text before hitting tab? It’s not a normal method of deleting text and inserting an indent, even though that’s what the default behavior for that action is. I’d bet that not many people have ever done that intentionally.

Wrapping and auto-pairing are usually mentioned together, but really are separate in my mind. As I said before, I’d rather not have auto-pairing if it’s not done right. Wrapping is hard to screw up, though, beyond how you handle the selection after the surrounding characters are inserted. In a normal situation you’d rarely select text and type a quote character. It would delete the selected text and leave you with a quote. To actually quote a section, you’d likely option-arrow to the beginning of the sentence, type your quote, option arrow to the end of the quoted section and insert another quote². Wrapping means you can hold shift and option-arrow from one end of the quoted section to the other, type quote once and be done, cursor ready to go at the end of the quote.

Service features

These features don’t even need keyboard shortcuts; they do just fine as menu items. Out of the way, but great tools to have available. Converting a selected block of lines into a list and batch reference link pasting from the clipboard are good examples. They are in no way interfering with your normal writing tasks. Learn to use them when you want to, and once you do you’ll be that much happier.

Other features such as footnote insertion and connection are advanced tools that should be connected to non-standard shortcuts, but ones that are easy to work into your habits if you choose to.

Link pasting behavior and reference title auto-completion should happen automatically but intelligently. Reference title completion is a huge timesaver if you have a group of reference links at the very top or bottom of your document and not visible on your screen from the current location. If your document is long enough for that to happen, you’ve probably forgotten the exact title you used for each reference. Get it wrong and you’ll have broken output. Type-ahead autocompletion prevents you from having to scroll to a document boundary, check the list, jump back and type in what’s probably only 5-10 characters.

Link pasting behavior is a little sketchier. I believe that Elastic Thread’s innovations are headed in a very positive direction. Selecting text and pasting a link should link that text. I’m willing to concede that–as we implemented in nvALT–the behavior might be best with a modifier key on V, rather than replacing the standard behavior for the “paste” key combination. Same with pasting a standalone link and having it automatically surrounded with angle brackets to create a self link, or preceded by “[]: “ if it’s at the beginning of a line. V works nicely in both situations, with different behaviors based on context and selection.

Regarding syntax highlighting in text editors

I’m a big fan of the subtle highlighting that Byword does. Markdown text is designed to be readable, and dimming the markup and emphasizing marked up text appropriately just makes it that much more readable for me. iA Writer’s ability to pull the leaders on ### style headlines outside of the left margin also has this effect. I don’t like color changes or size changes. I do not want my plain text changing scale and hue while I type. Keep it simple, make it beneficial and unobtrusive.

Moving forward

I’ve already implemented almost every one of these features in one form or another across my own projects. Markdown QuickTags, for example, does about 80% of what I’ve mentioned, but it does it in a web browser textarea. Javascript doesn’t allow for the clean implementation that the Cocoa Text System does, and editing in a web view is not my first choice (or even my third or fourth). The Blogsmith Bundle for TextMate also has many of these features, as well as a somewhat dizzying array of additional writing tools, providing an enhanced environment for web writers. It was a playground for my ideas, and a way for me to weed out what was actually useful and what was a hindrance. Now I just want the fruits of that research brought to bear in an elegant, dedicated Markdown editor.

The tools I’ve built in System Services are handy because they’re application-agnostic and allow keyboard shortcuts and behavior to be consistent across editing environments. They’re slow, though. Having their functionality built in to my primary writing space would be much more ideal. Based on downloads and traffic, I think a few people agree that they’re useful tools. Elegantly implemented within an app, I think they’d be dynamite.

That’s enough of a rambling response for now. I’ll end by once again saying that this is fodder for critique among the plain-text faithful. These are my personal desires, but they’ll never come into being without being passed through a gauntlet of thoughtful debate. If I haven’t lost your attention, I’d enjoy hearing more responses. Then let’s make the best damn Markdown editor ever.