Paste puts wrong line endings in

Nobody has claimed this yet.

I'm on a Mac OS X 10.9.5. To reproduce this:
1. Open a text document in BBEdit. Make sure the line endings are set to "Unix (LF)".
2. Copy some text from that document.
3. Paste the text into a MacDown document.

Result: the line endings in the MacDown document will be carriage returns (^M if you look in something like `less`).

The expected result is that the line endings get pasted in as they were in BBEdit, that is, as LF.

One consequence of this is that, while the text looks ok in MacDown's rendering, it won't work in pandoc, which will not treat the CR like a line ending and thus all sorts of chaos ensue.

A solution is for MacDown to always paste in LF and never CR or CRLF. Alternatively the line endings could be converted upon saving/closing, I suppose.

I tried a few other apps and all of the text I pasted from them seemed to have the correct line endings. Interestingly TextEdit seems to do the same thing, if I paste text into it (that is, text from BBEdit has ^M), but as soon as I save it, the newly copied line endings show up without the CR.

(My own solution right now is to replace them myself with `perl -pi -e 's/\r\n?/\n/g' filename.md`.)

(I'm not sure exactly what the problem is here. Maybe MacDown is somehow not grabbing the right form of the text for pasting?)

No file or test is named. First reproduce the paste from BBEdit into MacDown with Unix (LF) line endings, then locate MacDown's paste-handling entry point. Done means pasted text retains LF rather than CR and remains correctly usable by pandoc.

Written by the indexing model from the issue text.