What does "cr" do in the split block? You can't convert a list to it, so it just brings me more confusion.
It stands for "carriage return" which is U+000D. Long ago, in the days when computer terminals printed on paper rather than displaying on a screen, starting a new line of text was divided into two actions: carriage return, which moved the print mechanism to the left margin, and line feed (U+000A), which moved the paper up so that a new, empty line was in position under the print mechanism. Text files contained those two characters at the end of each line (in the order CR then LF, because the carriage return operation took a relatively long time, and the character after the CR might be printed while the carriage was only partway returned, so it would be printed over the old line if it were a printing character, but the line feed could happen while the carriage was moving without problems). The Model 37 Teletype introduced a renaming of line feed to "new line," which triggered both CR and LF actions at once. Operating systems developed after that just put NL (U+000A renamed) between lines in text files, whereas older systems put the two character CRLF sequence between lines. (I vaguely recall that some system at some point used just CR in text files, but you're unlikely to encounter such files nowadays. Unless Windows still does it.)
TL;DR: You can ignore the CR option in that menu. Just use SPLIT BY LINE.
So, it's the character C-like languages use \r to represent?
Yes.
Okay.
Unless you run into an issue with extra empty items in split by line, which I have ran into when doing the advent of code (yes, CRLF is still used, although I'm not sure which systems).
Windows does, I think.
So, it's the character Javascript language use \n to represent?
Windblows?
Yeah. I'm saying that Windows is bad in a single word.
Yeah, nevermind.
OHHHH, I get it! 
I don't like all the Windows hate. Windows is a fine operating system that functions like a modern-day operating system. Just because Microsoft is slowly making user quality of life bad, doesn't mean it's a bad operating system.
Correct.
I do use Windows, but it can be bad.
Ugh, are you saying that SPLIT BY LINE treats CRLF as two line breaks instead of one? I thought we fixed that.
Wait, what!? Can I have some context please?
I'm not sure what question you're asking, but I'll try to guess:
The subject under discussion is how multiline text is represented in text strings. Linux and MacOS represent
foo
bar
as foo\nbar but I guess Windows still uses the older foo\r\nbar notation. By convention \r\n should be treated as a single line break, but I think @ego-lay_atman-bay is saying we treat that sequence as two line breaks. You can't just ignore \r because there are still text files in the world that use that by itself as a line break, so the correct rule is to ignore \r iff the next character in the input string is \n.
That's what I want context on. Everything else I understand.
CRLF is 2 characters, and is used by Windows. Other operating systems just use LF, which is one character. bh is saying that Snap! treats CRLF as 2 line breaks, instead of just one like it should.
