I don't understand why tools view line endings as a "OS preference" and something that can be changed willy-nilly.
Memory usage, speed, even correctness can be affected by changing newlines if a language supports string literals that span lines.
And who are these users on Windows editing documents that need \r\n anyways? Apart from the built-in Notepad which handles \n uselessly, I'm coming up short on why anyone would care. It's not like the Windows tools (find, fc, and so on) are that popular.
Apparently, our customers are the users who need carriage returns. Instead of telling them to fix their configs and remove CRs from their source code, we decided to make things Just Work™.
On Windows, it's not hard to get CRs in your source. With the default git config, cloning a repo gives you text files with CRLFs. Other source control systems do this as well. Many editors on Windows default to CRLF, but even those that auto-detect line endings won't help if your source control munges the lines.
Yeah, git's default config also corrupts files by playing with line endings. Meaning the hash of a file on my Windows disk is different than on Linux. Meaning my strings are now shorter/longer. It confuses me just as much in git.
I wonder what editors they're using on Windows that it matters. But good that you're listening to customers.
I think it's the default thing on Windows. Editors just add the the \r\n. That's what VisualStudio does yes? I don't really understand why \r\n is a thing anymore.
"If the first argument to String.replace() is a string,
only the first instance of that string is replaced. To
replace all instances, a regex is necessary"
That's not that much advanced javascript knowledge.
I disagree. I think fault lies with the language designer(s) for putting the equivalent of a pull-handle on a push-door. The only way to reliably avoid this error would be to spend an inordinate amount of time reading documentation, dutifully examining every aspect of basic functionality for unusual behavior. Every other string replace method I've encountered does global replace. Java's String.replace(), STL's std::replace, PHP's str_replace, Python's string.replace(), all of them replace every instance. Given this precedence, it's entirely reasonable to assume JavaScript works the same. Unfortunately, it doesn't.
I've been writing JavaScript off-and-on since I was 12. I've used Node.js extensively enough to find bugs in it, including one that ended up being a bug in V8[1][2]. If I'm not an experienced JavaScript developer, then very few are.
It's not necessarily "advanced", but it is unexpected behavior I think. I've run into this same sort of issue myself. It didn't take ages to figure out, but it was annoying. It's one of those things that separates an experienced JavaScript dev from the rest.
"You could stare at that function for hours without seeing
the problem. It requires knowledge of how JavaScript’s
String.replace() works:"
Okay, but "knowledge of how JavaScript's String.replace() works" is showing that the experience of those guys is not the greatest. I'm pretty sure every decent JS developer knows this after a short amount of time, because "String.replace" is used pretty often.
"Floobits works pretty well most of the time."
Matt Kaniaris - Co-founder, Floobits
Can I suggest you change this? Makes me think it's not ready.. and "pretty well" "most of the time".. don't think I would want my team using it. Lost time is expensive.
I agree it's unprofessional. I put it there as a joke placeholder and forgot about it. I asked Christopher Groskopf if I could use https://twitter.com/onyxfish/status/431567402497609728, but then got distracted by the dozens of other things on my TODO list. Thanks for the reminder.
Memory usage, speed, even correctness can be affected by changing newlines if a language supports string literals that span lines.
And who are these users on Windows editing documents that need \r\n anyways? Apart from the built-in Notepad which handles \n uselessly, I'm coming up short on why anyone would care. It's not like the Windows tools (find, fc, and so on) are that popular.