When pasting existing copy with solo carriage returns \r these aren't rendered by SlateJS
Given This has a different new line\r\r\r\rThis is the final line. in the clipboard when pasting into Slate no lines are rendered as shown below.
SlateJS vs Draft JS

That the carriage returns are correctly rendered as shown in Draft JS
Developers can write custom deserializer rules in their paste handlers that convert '\r' to newline at least as a work around.
Could be solved here:
I'm not sure what the most standard behavior is though. I know nothing about the differences between \n and \r enough to make the decision. If anyone has prior art to point to that would be great!
In terms of OS, the enter representation is:
\r for Mac before OSX\n for OSX Mac and Unix\r\n for WindowsWhen doing a search replace, I search for \r\n first, then \r and \n. If you don't do the Windows style first, you end up with too many [ENTER]s.
@thesunny but shouldn't we fix this in the slate-plain-serializer then to properly handle the Windows-style breaks?
Oops, sorry, I actually hit the wrong button. I didn't mean to close this!
My naive solution about this:
https://github.com/zhujinxuan/slate-better-soft-break
I'm fairly sure this is still an issue for the basic plaintext pasting. If anyone wants to help solve this, I think it would involve changing the default logic to split on any of the line break combinations instead of just \n in the insert_data command of withReact.
It looks like this issue is also occurring with plain text with normal \n newlines in 0.57.1.
I opened a PR to fix both styles of newlines: https://github.com/ianstormtaylor/slate/pull/3472
Most helpful comment
Developers can write custom deserializer rules in their paste handlers that convert '\r' to newline at least as a work around.