Diff Match Patch is a high-performance library in multiple languages that manipulates plain text.

Following on from #58, I've kicked off the conversion of diff-match-patch starting with @NeilFraser's starting point as the first commit. I've included the built copy for now, though I may strip that out and rebase it based on feedback.

One interesting thing between Neil's built version and my built version:

diff --git a/typescript/built/diff_match_patch.js b/typescript/built/diff_match_patch.js
index 8fbb030..dafa48a 100644
--- a/typescript/built/diff_match_patch.js
+++ b/typescript/built/diff_match_patch.js
@@ -387,7 +387,7 @@ var diff_match_patch = /** @class */ (function () {
      */
     diff_match_patch.prototype.diff_linesToChars_ = function (text1, text2) {
         var lineArray = []; // e.g. lineArray[4] == 'Hello\n'
-        var lineHash = {}; // e.g. lineHash['Hello\n'] == 4
+        var lineHash = Object.create(null); // e.g. lineHash['Hello\n'] == 4
         // '\x00' is a valid character, but various debuggers don't like it.
         // So we'll insert a junk entry to avoid generating a null character.
         lineArray[0] = '';

Not quite sure why typescript goes that route to make an object with a null prototype (that still behaves like an object).

What works

• Base tests ✅
• Speed tests ❌
  • The speed tests use diff_match_patch_uncompressed.js which is not generated (by name) here
• Typing! ✅

Next steps

• [ ] Determine how well the types line up with that of @types/diff-match-patch to ease migration
• [ ] Make speed tests run
• [ ] Determine how the uncompressed and compressed versions will be stored (I need direction here)

This simplifies the encodeURI function, using HttpUtility instead of Uri. Tests pass. I suspect this also to be more performant (although I didn't test this specifically).

like "message": "'Diff.==' ('(Diff) → bool') isn't a valid override of 'Object.==' ('(dynamic) →

"message": "A value of type 'Operation' can't be assigned to a variable of type 'int'.",
"startColumn": 27,
"endColumn": 54,

...

I'm trying to diff several files sometimes up to around half a megabyte in size and with some of them I get a "Invalid URI: The Uri string is too long." exception. This is using the patch_make function.

Running the example usage from here on the javascript version:

  const text1="this\n is\n a\n test\n";
  const text2="this\n wasn't\n a\n test\n";
  // Example code "as is":
  var dmp = new diff_match_patch();
  var a = dmp.diff_linesToChars_(text1, text2);
  var lineText1 = a[0];
  var lineText2 = a[1];
  var lineArray = a[2];
  var diffs = dmp.diff_main(lineText1, lineText2, false);
  dmp.diff_charsToLines_(diffs, lineArray);

Causes this exception:

Uncaught Error: Null input. (diff_main) at diff_match_patch.diff_main (:2:190) at :6:19

Compared with the same content, Java and OC return results are inconsistent! How can such a problem be solved?（相同内容对比，Java和OC返回结果不一致！这样的问题该怎样解决？ ）Java on the left and OC on the right

Hi tried to compare two ancient greek codices of the New Testament but it seems to failed since for the Vaticanus and Sinaiticus I only have βιβλοϲγενεϲεωϲ|ιυ||χυ|υιου as common bloc.

This change does three things:

1. Updates the Xcode project to support the latest Xcode (11.5),
2. Make the Apple recommended settings to the Xcode project, and
3. (most importantly) Updates the project and the code to use Automatic Reference Counting (ARC).

Closes #97

The last part of the example doesn't work because cleanupSemantic doesn't return the result.

I looked at the code and indeed the function doesn't return anything.

Qt4 is no longer supported by Qt.

Apart from that, porting to Qt5 should also improve the performance, as it has added QStringRef class and QString::leftRef, QString::midRef and QString::rightRef methods. I see that the code splits QStrings into substrings quite a lot, and it does so by making copies, but with QStringRef you can avoid making copies since QStringRef substrings reference the original QString.

I encountered this in Java (using patch_toText(patch_make(...)), but I can see it on the JavaScript demo page, too, and I saw a past Google Code discussion touch on it for a Python usage, plus some Go code working around it.

Enter the following into the demo page:

Old version:

a a

New version:

a a a

(I entered both with trailing newlines, but the behavior is similar without.)

Compute Patch gives:

@@ -1,4 +1,6 @@
 a%0Aa%0A
+a%0A

I would have expected something more like:

$ diff -u <(echo a; echo a) <(echo a; echo a; echo a) | tail -n +3
@@ -1,2 +1,3 @@
 a
 a
+a

(Hmm, I notice only now that diff-match-match disagrees with diff -u about the number of lines involved. (At least, I think that's what the ,4/,6 and ,2/,3 are?))

As a workaround, I can replace %0A sequences with the empty string, but as best I can tell, even that will leave various other characters escaped.

I'm a little confused as to why URL encoding comes into this at all. I would expect for Patch.toString() to avoid all that, instead looking like this:

        text.append(aDiff.text.replaceAll("\n", ""))                                                                                                          
            .append("\n");                    

(It seems strange that I need to remove internal \n characters at all. I haven't dug into it.)

The cleaner methodes like diff_cleanupSemantic not correct the last newline like expected. Sometimes (by multiple line insert/delete) the result grabs a newline character from the line before, and cut his own of. It would be better if complete lines are inserted/deleted. I made my own cleaner to correct this and I can post it here, but it should be done in the diff_cleanup.

(tested only with the cs code)

I like this library and would like to give back: This PR converts the Javadoc in the C# source code to C# XML comments. With these changes, each class's documentation would be made usable by IDE's.

Notably, this PR does not affect functionality, compat, etc. in any way, so there is no risk accepting this PR. Aside from the documentation convertion, my IDE auto-formatted the opening curly brace to start on the next line, as is the norm in C#.

Edit: This PR is easier to review with whitespace ignored: https://github.com/google/diff-match-patch/pull/128/files?w=1

This is useful for projects that use Typescript (e.g. a Visual Studio Code Extension). Tested using the same logic as is present in the Patch Demo. "visualSilicon" has also submitted a CLA for contributions to Google open-source projects.

In the first sentence in the section about a word mode:

https://github.com/google/diff-match-patch/wiki/Line-or-Word-Diffs#word-mode

Computing a word-mode diff is exactly the same as the line-mode diff, except you will have to make a copy of diff_linesToChars and call it diff_linesToWords.

The function should be renamed to "diff_wordsToChars", not "diff_linesToWords".

Because words will be mapped to single chars, if you do the suggested modification. Analogous to lines that will be mapped to single chars in the original function.

Hi,

I yesterday ran into a problem that my diff implementation (adopted from the internet) in some cases actually doesn't work reliably.

Suppose I have a bit stream of zeros and ones, called simply "mine" (99658 bits) and "theirs" (99655 bits). These represent low-level magnetic information of two full revolutions of one and the same track on a 2DD floppy (nominally 100,000 bits).

Apart from being of different lengths (theirs being by three bits shorter than mine), there is also a difference in the middle - 34,425-th bit is different, thanks to magnetic deterioration. Otherwise, the two bit streams are identical.

My implementation of the diff algorithm produces the following script that transforms mine into theirs (unlike the numbering in OpenOffice Calc, the numbering of bits is zero-based, hence off by 1). The first two seem to successfully deal with the difference in the middle. The latter two fail to remove the tail three extra bits in mine.

• insertion of 1 bit from theirs at 34424 into mine at 34424,
• deletion of 1 bit from mine at 34424,
• deletion of 1 bit from mine at 99646,
• deletion of 1 bit from mine at 99650.

Because I've exhausted all my skills, I would like to ask if anyone could check my implementation of the diff algorithm and eventually fix the bug that's inside. Although I read Mr.Myers's paper "An O(ND) Difference Algorithm and its Variations," I'm not much more clever than before. The diff algorithm is implemented here (circa 100 lines of actual code): https://github.com/tomas-nestorovic/RIDE/blob/master/Main/src/Diff.h

Edit: Attached mine.txt and theirs.txt with respective bit streams. theirs.txt mine.txt

MANY THANKS IN ADVANCE FOR ANY RESPONSES! :-)