Pasted copy with carriage returns doesn't render the carriage returns

[adrianclay]

bug

What's the current behavior?

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

What's the expected behavior?

That the carriage returns are correctly rendered as shown in Draft JS

[DamareYoh]

Developers can write custom deserializer rules in their paste handlers that convert '\r' to newline at least as a work around.

[ianstormtaylor]

Could be solved here:

slate/packages/slate-plain-serializer/src/index.js

Line 30 in 2bf04b4

nodes: string.split('\n').map(line => {

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!

[thesunny]

In terms of OS, the enter representation is:

• \r for Mac before OSX
• \n for OSX Mac and Unix
• \r\n for Windows

When 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.

[ianstormtaylor]

@thesunny but shouldn't we fix this in the slate-plain-serializer then to properly handle the Windows-style breaks?

[thesunny]

Oops, sorry, I actually hit the wrong button. I didn't mean to close this!

[zhujinxuan]

My naive solution about this:
https://github.com/zhujinxuan/slate-better-soft-break

[ianstormtaylor]

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.

[thallada]

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: #3472