Nested editors, kind of.

I am trying to build a table in markdown which is WYSIWYG, for the most part it is straight forward, using a ViewPlugin with replace decoration for a custom table html element. Then building some extra elements for adding rows, columns, and similar stuff with also custom key-maps, nothing huge.

But the problem is that I need multiple editor instance within the table cells which should share history with the main editor, and it should be connected to the ranges for the cell so that they are parsed correctly, and I am not sure how do I go about it.

Somewhat similar to:

Thanks,
Dex Devlon.

This should be possible (if somewhat messy) using a technique similar to the split view example. But you’ll have to offset your change sets by the current position of the sub-document when forwarding them between the cell editors and the main editor (which should be possible by iterating over them with iterChanges and building up a new changeset with the same insertions but offset position).

If I understood this correctly, I would create a sub-editor for each cell, and while forwarding the changes from the sub-cell editor to the main editor, change the offset(the position of the ranges).

That makes sense, but I don’t think so it takes into account that some parsing should not happen inside of the table cell, like headers, or multi line code-blocks in markdown, for these I would need to somehow tell the subeditor inside the cells to not parse these, I am sure there is a way for it, maybe you could help me here. My best guess is to remove certain inline parser from the markdown parser, and make the editor only allow for a single line. But there might be a better way.

Also one last thing, how should I go about optimising this? As tables have first parsed and then would be converted to the table widget, my best guess is to use view port and only render the the parts of the table in it, but then I am not 100% sure how I would calculate the height of the widget. Or I should not bother? As the subeditors would be optimised before hand for viewport.

Again thanks a lot! This was very very helpful,
Dex Devlon.