reversing a text diff?

[Pomax]

I know there's a reversePatch for structured diffs, but is there a built in reverse function for the "normal" text diff? I'm not working with structured diffs, so having a way to migrate files both ways using regular text diffs would be super useful.

[ExplodingCabbage]

formatPatch(reversePatch(parsePatch(patchStr))) should do the trick, no?

[ExplodingCabbage]

(But no, nothing built-in right now that combines those three operations. I am ambivalent about whether having such a function would be a good thing. I think one can make a reasonable case that it's wholly proper that if you want to manipulate the patch, you should parse it into a structured representation first, manipulate that, and then serialise it as a string again, just like you generally would if you wanted to mutate some JSON or XML or something.)

[Pomax]

Except plain text has no structure beyond just "what the text was", there's nothing to parse other that perhaps "split on newlines" =)

As concrete example, I need to sync a multi-user clientside with a server backend, for freeform collaborative plain text work. There is nothing clever to do there other than creating and applying plain text diffs on both sides.

[ExplodingCabbage]

I don't understand your reply. Did I misunderstand your original post? I took the phrase

the "normal" text diff

to mean a patch in unified diff format, like createPatch would output, and indicated how to reverse that: formatPatch(reversePatch(parsePatch(patchStr))).

By the "normal" text diff did you actually mean the output of a function like diffChars?

[Pomax]

It would have helped if I'd originally given the example code: yes, I meant diffChars.

[ExplodingCabbage]

Hmm. This is almost trivial:

export function reverseDiff<T>(diff: ChangeObject<T>[]): ChangeObject<T>[] {
  return diff
    .slice()
    .reverse()
    .map(({ value, added, removed, count }) => ({
      value,
      added: removed,
      removed: added,
      count
    }));
}

... except that this doesn't quite return the right result in cases where non-identical tokens have been treated as equal (as happens by default in diffWords, or as happens when using the ignoreCase flag). And indeed we cannot return the right result in that case because the value property will contain the new value, not the old value, and the old value simply isn't recorded in the change objects at all.

This is probably fixable in principle by adding an oldValue property to change objects, which I've considered in the past.

[Pomax]

Ah, yes that would make it tricky... might be a nice thing to add if the user calls diffChars/diffWords with an options object, with a special boolean property that lets them say they want the old value recorded?