copy event handler produces more newlines than the user typed for "text/plain"

[ganthern]

Reproduction:

• type some text with some empty lines in Demo.html
• select it, then copy it with ctrl + c or the context menu
• paste it into an editor that does not handle html (gedit on linux, notepad on windows. The text editor on MacOS can do it.)
• see that empty lines are duplicated

I'm aware of the point made in #421 as in, the html -> plain text conversion is not well defined, but still think this is worth fixing, since it's an inconsistency related to arguably the most fundamental usage of the editor (typing something in with your keyboard).

My current workaround would be to register my own copy event handler that replaces the "text/plain" clipboardData with the result obtained by calling getSelectedText, which does not have this issue.

Would it be feasible to use getSelectedText internally to get the plaintext part of the clipboardData? That way, they could never diverge and the tree walking approach seems more correct anyway. I'd be willing to try and make the needed changes to the copy event handler in any case, if there's capacity to review the resulting PR.

Notes:

• the produced html when typing in the editor is completely fine
• therefore, the content of the "text/html" data also doesn't have any problems.

[neilj]

I've updated the default to use the same algorithm as getSelectedText — I've also added a toPlainText config option to allow you to provide a function for converting the HTML to plain text however you want (at Fastmail we use this function).

[ganthern]

That's awesome, thank you! Just need to update now :)