Kyle J Strand

@sehz Sorry, I think I wasn't clear; those are errors that already exist in the code, and are considered "nonrecoverable" (they're part of the `UnrecoverableCheckStatus` enum). My question is whether...

Native UIs for major platforms: I have considered switching to Kakoune several times but always bounced back to gVim because I can install it everywhere and don't need to use...

@BurntSushi Would treating `\r` as an end-of-line character, and `\n` as *non*-EOL if preceded by `\r`, be an acceptable change? This should be doable in a DFA, I think, though...

But the existing implementation is *more* wrong, so I'm not sure I understand that as an objection.

(Also, just last week I actually did run into something that uses `\r` on its own as EOL by default: Putty in serial mode! I was shocked.)

@BurntSushi That's odd. I've used `re` in Python 2.7 on Windows pretty extensively, and I'm sure I've used `$`, and I know the files I was working with had carriage...

For Javascript and Java, does `\r` on its own match as a newline anchor? `\r` on its own is apparently considered a newline character by Unicode. Is there any objection...

@mitsuhiko Hmm. If the interpreter [here](http://eloquentjavascript.net/code/) is correct, JavaScript also returns a four-element array here: `'1\r\n\r\n4'.split(/$/m)` This is obviously not correct on Windows (there are only two line-endings there).

Sorry, I meant 5 elements, splitting on each of the `\r`'s and `\n`'s (so 4 matches, which is what I was thinking when I typed that). There should only be...

I don't believe you're interpreting that list of Unicode newline character-sequences correctly, because they list `\r\n` as a *separate entry* from `\r`. I.e., Unicode considers `\r\n` to be *one single*...