There’s a currently undocumented (and thus not part of the stable API) function closeHistory exported from the history module. You can do state.apply(closeHistory(state)) to force a new history event to start. I guess I should make this a proper command and document it.
Another thing worth thinking about is for the outside to know when a new undo event happens and it’s content (steps).
ATM in the collab demo for example, steps are written whenever they are available which will usually be too often. The client will want to throttle sends in some custom way, but another useful option can be to know when an undo step occurred and send it. This will keep the logic of dividing steps into ‘chunks’ in one place (history) and sync the history and collab better especially in the case were steps are loaded into the undo on startup (as I proposed in the other thread).
Because it uses a private symbol, rather than a plain string, for its meta property, mostly because I expected addToHistory to be used by widely different modules that may not directly depend on the history module, whereas closing the history is a specialized thing that you probably only do when you’re already directly interacting with the history module.