I’m currently looking for a way to handle the paste event inside a code block in a special way. I would like to keep the pasted content as plain text without any processing.
With the current ProseMirror API I haven’t seen a way to do this as pasted text is always converted into a DOM structure that strips away whitespace and creates HardBreak nodes .
One way to handle this would be to hard code the behavior into ProseMirror by checking if the node that is pasted into is a CodeBlock by checking the isCode property and to skip any processing steps in this case and to directly use the plain text content. I can imagine that this might be a good default behavior for many users, but not being able to customize this might still be a problem for some.
Alternatively we could try to give more control to the library user and allow more customizations around clipboard handling. There’s another issue concerning clipboard handling, which would need more control on the library level. Would it be an option to expose an additional event with the raw clipboardData data which when used would skip all default processing steps and would be expected to return a Fragment?
My current workaround is to use the transformPasted event to turn the processed content back into a single TextNode if the current selection is inside a CodeBlock. Unfortunately this is very hacky and I don’t have a way to get back the lost whitespace with this approach, which is pretty important when pasting code.
What about exposing a transformPasteEvent subscription for cases where full control is needed? A subscriber could return a Fragment and the default processing would be skipped. Returning null in such a subscription would fall back to the default processing which should work well in most cases. This would allow custom handling of the Files type as described in #402 and also enable this specific use case of using the raw pasted text when pasting inside a code block.
Maybe there’s already a better approach for this specific use case with the current API?
Ideally, the DOM parser should support scoped rules which are selected based on parent nodes. I’m unfortunately tied up with other stuff at the moment, so it’ll be a while until I find time to work on that.
As a bandaid, I’ve added a domPaste event, which works like domDrop, and allows you to override the way the editor handles paste events.
Pasting content copied from a HTML page into a code block, I want to insert the text/plain version because it includes sensible new line separators between content.
Pasting plain text into a code block, I want to insert the text/plain verbatim.
I agree, and there will be, but there’s some rather serious problems with the way I’m currently handling paste (in terms of parsing the structure of the pasted content), and I’d like to have a somewhat clearer view on how I’m going to fix those before I add hooks that interact with them (so that I can get them right the first time).
Clipboard handling is my next main priority, so I hope that it won’t take too long to get progress here.
