Next post Previous post

Elements 1.5 adds Markdown

November 3, 2010 at 11:25 PM by Dr. Drang

And there was much rejoicing (with a certain amount of bitching).

The rejoicing

Elements 1.5, the latest version of the iPhone text editor that syncs via Dropbox, appeared in the App Store either last night or this morning, and came with a huge list of improvements in the release notes. Among the best are

  • You can now create sub-folders to better organize your ELements files.
  • Added support for viewing Markdown formatted files in Elements (.md, .markdown, .mdown, .mdwn).
  • Added new preference to show file extensions. With them enabled, you can change a file type between txt and Markdown.
  • Added Markdown preview support.
  • Added support for opening Markdown files from external applications that support it.
  • Added support for emailing a files contents inline in addition to as an attachment.

You had to figure Markdown support would come to Elements eventually, as Second Gear (Elements’ developer) had already created much of the infrastructure for it in MarkdownMail. And competitors like PlainText, from Hog Bay Software, had subfolders, so that was expected, too.

Here’s how Markdown in Elements works: You first have to create a file with one of the Markdown extensions that Elements recognizes (I was glad to see .md on the list, because that’s what I’ve been using for years). You can either create this file on your computer and save it in your Dropbox/Elements folder, or you can create it within Elements itself. To make sure a file created within Elements has the proper extension, you’ll have to turn on the new Show Extensions preference.

This allows you to edit the extension just as you would the rest of the file name.

Markdown files have a button in the bottom toolbar that looks like the Daring Fireball logo.1

Tapping that button will render the file.

I don’t see mention of it in the release notes or the About Elements screen, but I assume the rendering is being done by David Parsons’ Discount library, just as in MarkdownMail. One nice thing about this library is that it supports tables, so tabular data can be displayed in columns without necessarily resorting to a monospaced font. One of my train schedule files, for example, would look like this:

I have to say this would look better with a little CSS to separate the column headings a bit more. Since Markdown allows HTML, I’ve tried adding <style> tags, but that doesn’t work. As I said in my post on MarkdownMail, user-defined stylesheets would be a nice addition.

The bitching

I don’t want to end on a sour note, but there is one new “feature” of Elements I don’t like. From the release notes:

  • Now using Windows style CRLF line breaks so files render properly in Windows based text editors.

Ugh. As with the byte order mark (BOM) at the beginning of every Elements file, this change will now add characters to my file that

  1. I didn’t put there, and
  2. Interfere with the processing of the files by Unix text tools.

I certainly understand the need to accommodate Windows users, but I’m not happy that I have to be inconvenienced to do so. Here’s my Twitter exchange with Second Gear this morning

@secondgear Love the Markdown, but CRLF line endings?! Why not an option for LF to accommodate Mac users?

@drdrang because CRLF works on all platforms. Preferences are evil.

@secondgear I appreciate the simplicity of one format, but some Unix text tools don't like the CR any more than they like the BOM.

@drdrang if you’ve got specific use cases feel free to email them to support@secondgearsoftware.com and we’ll consider it.

My interpretation of this is that I’m SOL. If you were Second Gear, which would you choose?

But still I will complain, because I feel I’m being wronged. I create a file on my Mac that has no BOM and proper Unix line endings, and I save it in my Dropbox/Elements folder so I can read and edit it on my phone. Later, I do edit it on my phone, and when I open it again on my Mac, it has a bunch of new bytes that I didn’t add.

How can this be a problem? Let’s look at my favorite file, the one that keeps track of my weight. It’s called “Weight.txt” and looks like this:2

01/01/10   195.0
01/02/10   196.0
01/03/10   195.0
01/04/10   196.0
01/05/10   196.5
01/06/10   196.0
01/07/10   195.5
01/08/10   196.0
01/09/10   196.0
01/10/10   196.0

Looks innocent enough, but a hex editor (xxd) shows this:

0000000: efbb bf30 312f 3031 2f31 3020 2020 3139  ...01/01/10   19
0000010: 352e 300d 0a30 312f 3032 2f31 3020 2020  5.0..01/02/10   
0000020: 3139 362e 300d 0a30 312f 3033 2f31 3020  196.0..01/03/10 
0000030: 2020 3139 352e 300d 0a30 312f 3034 2f31    195.0..01/04/1
0000040: 3020 2020 3139 362e 300d 0a30 312f 3035  0   196.0..01/05
0000050: 2f31 3020 2020 3139 362e 350d 0a30 312f  /10   196.5..01/
0000060: 3036 2f31 3020 2020 3139 362e 300d 0a30  06/10   196.0..0
0000070: 312f 3037 2f31 3020 2020 3139 352e 350d  1/07/10   195.5.
0000080: 0a30 312f 3038 2f31 3020 2020 3139 362e  .01/08/10   196.
0000090: 300d 0a30 312f 3039 2f31 3020 2020 3139  0..01/09/10   19

The first three hidden bytes (EFBBBF) are the BOM, which I’ve complained about (giving a specific use case) before. My complaint today is about the 0D0A (CRLF) pairs that appear at the end of each line. Unix text files (and the Mac is a Unix machine) should have only the LF—that’s what tools like Perl and Python expect.

Suppose I run this simple Perl one-liner on “Weight.txt” in the Terminal:

perl -e 'for(<>){chomp;print;}' Weight.txt

It’s supposed to eliminate the line breaks and print out the file as one big, long line, like this:

01/01/10   195.001/02/10   196.001/03/10   195.001/04/10   196.001/05/10   196.501/06/10   196.001/07/10   195.501/08/10   196.001/09/10   196.001/10/10

With “Weight.txt” having CRLF line endings on my Mac, it prints out nothing. Nothing!

I freely admit this is an artificial use case. I made it up not because I want to print my files as one long line, but to illustrate the weird behavior you can get with unexpected line endings. Perl and Python both know about the LF/CRLF issue and adjust accordingly, but they do that with the expectation that the line endings are appropriate for the platform on which they’re running. CRLF is not appropriate for the Mac (or Linux, or any other Unix).

What’s happening in the Perl one-liner is that Perl is not converting the CRLFs to just LFs when it reads in the file (as the perlport documentation says it will on a Windows machine). So when chomp strips the LFs, the CRs are still there. Terminal doesn’t like that and prints out nothing.

Since Second Gear isn’t helping me avoid this problem, I’ve written my own little script to return my Elements files to proper Unix form. I call it “fix-elements,” and it’s pretty simple.

#!/usr/bin/perl -i.bak -p
s/^\xef\xbb\xbf//;
s/\r\n$/\n/;

The options in the shebang line tell Perl to read in and print out every line of the file and to change it in-place. The second line strips the BOM, and the third line fixes the line endings. Running this on Elements files before feeding them as input to Unix text filters should ensure that the filters work as expected.

The wrapup

I see that my complaint is taking up about half the post, which isn’t really fair. I like Elements and use it every day; it’s my all-purpose iPhone note-taker. The line-ending and BOM problems don’t arise in daily use because decent text editors on the Mac, like TextMate and BBEdit, handle the foreign format gracefully.

But I’m not withdrawing my complaint. CRLF isn’t universal, preferences aren’t evil,3 and a text editor shouldn’t change the format of my files without my approval.

  1. Elements doesn’t require the ugly Courier Bold font; I use it to keep columns of data aligned. ↩

  2. I’m just showing the initial lines to give you a sense of what the file as a whole looks like. ↩

  3. If they are, Elements is surely Satan’s app, because it has lots of preferences that PlainText and Simplenote don’t. ↩

Next post Previous post