https://bugzilla.wikimedia.org/show_bug.cgi?id=54328
--- Comment #3 from Aaron Halfaker <aaron.halfa...@gmail.com> --- 1. Character vs. line offset I'd much rather represent diffs based on a character offset I'm afraid of representing position with something like lineno since linebreaks are differently defined between systems. Character offsets would also allow us to make changes to our diff detection strategy without changing the output. 2. Machine readable vs. human readable diffs Machine readable diff opcode formats tend to represent the full set of operations used to recreate a revision -- not just the context. A common format that I'm familiar with would something like this: a = "These are wrd." b = "These are words." { diff: [ { op: "equal", a_start: 0, a_end: 10, b_start: 0 b_end: 10 }, { op: "remove", a_start: 10, a_end: 13, b_start: 10, b_end: 10, content: "wrd", }, { op: "insert", a_start: 13, a_end: 13, b_start: 10, b_end: 15, content: "words", }, { op: "equal", a_start: 13, a_end: 14, b_start: 15, b_end: 16 } ] } 3. compressed format: I don't see the value in compressing the format given that the API doesn't really let you query for more than one diff at a time and diffs tend to be represented in few operations. However, we could simply represent each operation as a tuple with agreed upon field order: { op: "insert", a_start: 13, a_end: 13, b_start: 15, b_end: 18, content: "foo" } could be [ "insert", 13, 13, 15, 18, "foo" ] or if we really want to get a tight format (since the rest of the fields are derivable in a sequence of operations). [ "insert", 15, "foo" ] -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l