https://bugzilla.wikimedia.org/show_bug.cgi?id=19092
Conrad Irwin <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Conrad Irwin <[email protected]> 2009-12-28 02:59:08 UTC --- There is no "best" diff output, it depends on personal taste. The beauty of the output of a diff depends as much on the postprocessing of the output as the algorithm used, or the parameters with which it is used. The wikEdDiff uses a different theoretical approach, based on Heckel 1978, from MediaWiki, based on Myers 1986, which may or may not give better results overall. From memory, Heckel is generally better at spotting which strings came from where in the source, but can fail quite nastily if the source contains few unique words. In such cases it may generate very large diffs for very small changes - these failures are unintuitive, unlike the current failures, in which it's easy for a human to see why the computer has been misled (though I think they would be rarer in typical use, so maybe it would be an even match). The Heckel algorithm is, to my mind, quite beautiful in a language with inbuilt hashing, so a quick proof-of-concept should not be hard to whip up - though optimising it well enough to actually be used in MediaWiki might be a bit of a slog. (For further incentive, I have a primitive 3-way-merge tool based on Heckel which is wonderfully fun, you can safely fix a typo in the middle of a sentence while someone else moves the sentence to a new place, if we were to change the diff algorithm, we'd likely want the merge function to follow suit, though it's not necessary). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
