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
