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, 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.

[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??

[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.

[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.

[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ë]

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]

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.

[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: