Minimum number of lines for matching block

When you pick Extra|Compare Files from the menu, EditPad Pro asks for a file to compare the active one with. Near the bottom of the selection window, you will see the spinner box labeled “minimum number of lines for a matching block”.

The default setting is 3. You can set it to any number from 1 up to and including 9.

This value is used by EditPad Pro in the following situation. While comparing the files, it encounters a section of one or more changed lines. In the difference output, these lines are grouped into a single red block showing the original lines, followed by a single green block with the new lines. This is done because all those lines are most likely connected somehow: a chapter in a book that was heavily edited, a source code routine that has been modified, etc. Keeping those lines together maintains their logical connection so you can easily see what happened when inspecting the output of Extra|Compare Files.

To even better maintain the logical structure of the document, you can have EditPad Pro also include a few lines in the block that are identical in both versions of the document. This happens when you set “minimum number of lines for a matching block” to a number greater than one (1).

The setting indicates the minimum number of consecutive lines that are identical in both files that are required for EditPad Pro to stop grouping the modified lines and add the identical lines as an unchanged block. The graphical illustrations below make this clear.

First you see the old and new version of our test document:


Then we use Options|Compare Files, and set “minimum number of lines for a matching block” to one, effectively turning off the feature. This is the result:

You see that EditPad Pro detects the line “Version 2” as being inserted.
It also detects that the lines numbered 3 and 7 are present in both files, and that the blocks 1-2, 4-6 and 8-9 have changed. This is technically exact. It is the optimum solution. But logically it makes no sense. The arrow is broken into pieces.

If we try again and set “minimum number of lines for a matching block” to anything greater than 1, we get the following result:

Much better!  The “I created...” line is still included on its own since it does not follow a block of changed lines, but an inserted one.

However, the lines containing the numbers 3 and 7, even though they are present in both files, are displayed in the middle of the changed block as if they had been changed too. This way, our logical structure, the arrow, is kept together nicely and we can instantly see what happened: the arrow’s direction was changed. This was not at all so clear in our first comparison attempt.

Since you will not be comparing arrows but real documents such as source code files, the “minimum number of lines for a matching block” can be configured for the task at hand. Many source code files contain lines with nothing but a curly brace or a “begin” or “end”. These lines add structure to the source, and not content. When comparing two versions of a piece of source, these lines are likely to be matched all over the place, breaking up the logical structure of the source code in the difference output.

If things don’t look right, experiment with the “minimum number of lines for a matching block” setting.

See Also

Extra menu
Extra|Compare Files
Extra|Compare with File on Disk