Here is a potential use-case which I am wondering if Prose Mirror might support someday.
I am writing an app for novelists to write books. Its document model breaks up a project into many “files” which can be selected from a navigation. But it represents one “document” and undo/redo will include file creation/deletion and span edits across files.
Is using multiple editing surfaces something on the roadmap?
I am interested in a similar use case where I would like to only instantiate prosemirror on a paragraph at a time but maintain a consolidated document model. Any suggestions for how to approach this?
I suppose, with a few more events added to the history object, you could keep an external data structure tracking the order of history events in different editors, and override ctrl-z/y to multiplex the undos and redos to the correct editor instances.
I’m currently investigating a very similar use-case, where I’m wanting to use ProseMirror as a component of an editor for a more complex document model. Has there been any progress on this? I was thinking exactly what @marijn said last: if I could get some kind of event notification whenever PM adds a history entry, then I could simply record that in my global history stack and defer to PM’s own history methods when appropriate.
I was also wondering: If I preserve the Doc and History from a PM instance which has been destroyed (by navigating to another screen), could I create a new ProseMirror with that Doc, do pm.history = oldHistory, and have it just work?
So, unfortunately, history tracking in ProseMirror is rather involved, and exposing what the history is doing through a few events seems like it’d open you up to all kind of problematic corner cases (what about changes that aren’t added to the history? what if a change you’re trying to undo is superseded by later non-history changes? what if client code messes with the history through, for example, backToVersion?). A model in which you associate the history’s current ‘version’ (as returned by getVersion) with some history position in your own model, update it when the document changes, and go back to it when undoing, seems more promising. Though implementing redo in that approach is tricky.
I see where you’re coming from. In my case, however, I don’t foresee needing to make non-history changes (unless there are some trivial/common non-history changes I’m not thinking of), nor do I intend to undo multiple steps at a time with backToVersion. I could see the version-based approach working, but it does make redo a lot more complicated. An alternative, though more involved, solution could be to forego the built-in history completely and simply subscribe to transform events from the editor and store Doc instances from tr.before and tr.after. Then just replace the editor’s document as needed.
Yes, in a situation where all changes ‘count’ for the history, this is a solid (and much less complicated) solution.