> Having a rich set of changes gives us way more options for merging - eg, they could be merged in a conflict-free way if we want. Or with a custom UI or whatev

> Having a rich set of changes gives us way more options for merging - eg, they could be merged in a conflict-free way if we want. Or with a custom UI or whatever. Its strictly more information that you can generate with diff-match-patch. this reminds me of an event store from event sourcing. the file itself is just the on-disk persisted format of the 'permanent undo log'. Depending on how fancy the system is, one could view all of the changes, the mark a particular change in the past as 'deleted', or modify that change's parameters, or maybe even do a 'this sequence of changes replaces that change there' operation. on disk, there are just more events added to the event stores, while onscreen, the file is re-rendered / re-projected anew to reflect what it would look like as ifthose changes were original. Surely i'm just poorly reinventing CRDTs or DAGs or similar, right? granted, i don't know how easy it would be to not cascade subsequent edit events if one of their past dependencies was gone, so we'd need to make the events be 'pure functions' (the X-eith thru X+N-eth words equal Y) rather than imperative statements (add text at offset X with content Y)