13298 Mystery mismatch

[chrisjj]

That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it

For the record, that is exactly what I do see when BC is working better e.g. at the caret here:

[chrisjj]

it says they're changes that "should" be considered unimportant, not "must".

Cute.

Aha. I don't think keeping that info from users was a smart idea.

What, that we made a design decision?

No - that BC may decide not to apply the user's Replacements.

[Zoë]

Not according to the documentation, Craig.

The documentation doesn't say one way or the other. At best, it says they're changes that "should" be considered unimportant, not "must".

Aha. I don't think keeping that info from users was a smart idea.

What, that we made a design decision? We make thousands of decisions about how features should work; we aren't going to document all of the things we decided not to do.

That's a faithful execution of the Replacement the user asked for. That's exactly what I want as per "Replacements identify repetitive changes that should be considered unimportant."

Craig, I cannot imagine when I would find it useful for BC to apply my replacements "optionally". Replacements are no use to me if I cannot trust BC to apply them consistently.

As I said, we considered both approaches, and we believe that the current behavior is better in more cases. You're welcome to disagree, but you're not the only one we're designing BC for. In source code changes are frequently on a subroutine-by-subroutine basis, rather than over the entire file, so the current behavior is better since it isn't introducing differences that aren't there.

I'm sorry the current behavior doesn't work for you, but adding the alternate approach is a fairly complex feature and I don't expect us to get to it soon. BC has find and replace support and updates the comparison as it does so, so you can do a global replacement yourself to eliminate them as differences.

[chrisjj]

Replacements represent optional file changes.

Not according to the documentation, Craig.

With the current behavior, you can add "apples => bananas" as a replacement and it will only affect the middle line

Aha. I don't think keeping that info from users was a smart idea.

If, instead, we apply the replacements first, internally the files would be represented as:

bananas             | apples
bananas             | bananas
bananas             | bananas

Which would cause problems with the first line.

That's a faithful execution of the Replacement the user asked for. That's exactly what I want as per "Replacements identify repetitive changes that should be considered unimportant."

Craig, I cannot imagine when I would find it useful for BC to apply my replacements "optionally". Replacements are no use to me if I cannot trust BC to apply them consistently.

improving replacements is on our wishlist

Thanks. Good luck.

[Zoë]

Replacements represent file changes, so surely they must be applied first, if they are to work properly??

Replacements represent optional file changes. When we were working on the feature we considered both approaches and decided on the current one.

If you have these two files:

apples                 | apples
apples                 | bananas
bananas              | bananas

The first and last lines should appear as exact matches.

With the current behavior, you can add "apples => bananas" as a replacement and it will only affect the middle line.

If, instead, we apply the replacements first, internally the files would be represented as:

bananas             | apples
bananas             | bananas
bananas             | bananas

Which would cause problems with the first line. Doing replacements beforehand also causes problems if you have strings like:

ababababab

And you want to replace "aba" with "c". In that case you'll end up with something like:

cbcbab

The second and fourth "aba" substrings won't be replaced correctly because they've already matched a replacement. The current behavior allows the "c" replacement can occur for any of the "aba" substrings.

We may support doing pre-replacements at some point, but the current behavior is intentional. On the other hand, the initial alignment should be improved to better group characters, and if it did you wouldn't have had any problems here.

[Aaron]

The alignment does occur before the replacement. Expanding and improving replacements is on our wishlist, but the replacement does not currently try to push the alignment.

[chrisjj]

Re http://img844.imageshack.us/img844/4...gnment0nor.png

Aaron wrote*:

Thanks, Chris. I added these to our test cases. In this specific
example, the issue is that the alignment aligns the 0 in an unexpected
location. The alignment step happens before the text replacement step,
so by being misalighed, the text replacement does not match the text
sections.

Improving our intra-line alignment is on our wishlist. The only
workaround available in this case would be to mark "\30s\Loud" as an
unimportant grammar instead of using text replacements.

Thanks.

But re "The alignment step happens before the text replacement step, so by being misalighed", are you sure, Aaron? Replacements represent file changes, so surely they must be applied first, if they are to work properly??

[chrisjj]

That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it, which would make it harder to read.

Whereas currently it is impossible to read as a match. Please record my request to remedy this failure to accord with documentation and common sense.

Meanwhile, is there a workaround? I.e. a way to get BC to show all matches?

PS It would have been useful to have received this information fifteen messages ago when I asked the question.

[Aaron]

Hello Chris,

That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it, which would make it harder to read. It is a design and presentation decision and intentional behavior.

[chrisjj]

Now, returning to my first question (i.e. regardless of the issues of a) failure of Unimportant marking and b) unexpected alignment), why does the left side shows the s as mismatched (red) as opposed to matched (black), here:



Thanks.

[chrisjj]

At http://www.scootersoftware.com/vbull...40&postcount=5 Aaron wrote:

This is the screenshot I was referring to, but now that I re-review it I see the trouble it is having:
http://img846.imageshack.us/img846/1543/regionm.png

The 0's alignment is probably the cause. If you send in sample files I can add them to our test cases.

OK, I have made a stripped-down test case showing that same "0" unexpected alignment (with no Replacement):



and emailed the BCsupport.zip and left and right files.

[chrisjj]

Thanks for the easy to copy and paste text. Using the Open Clipboard to saving them to files I still see different text alignment results than your first screenshot.

Apologies - I have confused the issue(s) by reporting a second bug in this same thread. I have rereported separately under an an accurate Subject at http://www.scootersoftware.com/vbull...9832#post29832

... Your initial screenshot, however, shows different alignment details where the first \ is aligned to the front. I would need the requested files in order to try and reproduce that behavior.

OK... will do. Thanks.

[Aaron]

Hello,

Thanks for the easy to copy and paste text. Using the Open Clipboard to saving them to files I still see different text alignment results than your first screenshot. With this example, the first \ is not aligned at the front, so there is no "\" to match on. Your initial screenshot, however, shows different alignment details where the first \ is aligned to the front. I would need the requested files in order to try and reproduce that behavior.

[chrisjj]

I'm surprised Aaron. I get the fail with this simple test:

1 Click Start New Session, Text Compare
2 Enter in left \Curtain\2480002928225-1-5 and right R:\Curtain\30s\Loud\2480002928225-1-5
3 In Session Settings, enter the Replacement right \30s\Loud\ to left \
4 Inspect right \30s\Loud\

Expected: Unimportant blue
Observed: Important red - see http://img688.imageshack.us/img688/2293/regionv.png

[Aaron]

Hi Chrisjj,

Thanks for the screenshot. I tried recreating your files manually by typing out that line, but I'm not seeing the same behavior (alignment details) as you are. Please email us:
1) A pair of sample files
2) Your current support.zip (Help menu -> Support; Export)
3) A link back to this forum post for reference.

Thanks.