Hide Unimportant Differences bug?

[Cat]

In one of my files, a change from '>' to '>=' was considered an unimportant difference. Is this expected behavior?

[jeffhostetler]

Uh, no that shouldn't be the case. But then again, that depends.

What type of files are they and what are the ruleset settings for them?
Was the change in an area/context considered a "comment" (as opposed
to the "default" and/or "literal" context)?

For example, if it was inside a comment, we might treat it as unimportant
(depending on the settings).

You're probably talking about source code, so the "default" context probably
applies. (If it isn't in a comment or literal, it is in the default context.)
If that is the case, make sure that "Classify Differences as Important (Always Highlight)"
(under the "Default Context Guidelines") is checked at the bottom of the "Content
Handling" page for the Ruleset in question.

If that's not the case (or if I've rambled too much), please post a screen shot
of the region and we can go from there.

thanks
jeff

[Cat]

Source, not inside a comment. C#. I'll try your suggestion.

[Cat]

Each >= is not seen as a difference. Maybe the double // comment is causing this?

[jeffhostetler]

A couple of things come to mind:

[a] In that example, DiffMerge is only going to highlight the "=" and not the whole ">="
because that is the only character that is changed/added/deleted.

When you turn on "Hide Umimportant", does the whole line revert to black/white
with no background shading?

[c] I doubt that the "//" is causing any problems, but you might try deleting those
lines and see if that changes anything.

[d] Have you made any changes to the C# Ruleset? If so, you might want to reset
them and see if that changes anything.

jeff

[Cat]

[a] That was what I expected, too.

The line has no background shading. Looking closely, the added "=" characters are actually highlighted, but with the Unimportant color.
There is no indicator in the margin that this line changed, and there is no option to jump to this different line. That's the biggest annoyance.

[c] You're right; that didn't change anything.

[d] Defaults.

So they're clearly marked as Unimportant with the default ruleset.

[jeffhostetler]

Humph!

I created a similar test with a pair of files with a one character difference ("<" vs "<=")
and the line draws with the pinkish background and the "=" is highlighted. Near the
bottom of the window, it says "Changes: 1". When I turn on "Hide Unimportant", nothing
changes. In the status bar, it says "Ruleset: C/C++/C# Source".

If I look at the "Content Handling" page of the C/C++/C# Ruleset, the "Default Context Guidelines"
shows that "Classify Differences as Important (Always HIghlight)" is checked.

When I turn that off, I get behavior similar to what you are describing. When I toggle
"Hide Unimportant" on the menu, the "Changes: 1" display alternates between that and
"Changes: (0 Imp, 1 Unimp)" and the line is no longer highlighted.

Does this match what you are seeing?

jeff

[Cat]

Toggling "Classify Differences as Important (Always HIghlight)" does not change anything. Build 18729, if it matters.

[jeffhostetler]

The 18729 tells me that you have either Vault 5.0.1 or Fortress 1.0.1. The version
of DiffMerge included with them is feature-wise the same as the standalone 3.3.0
release. So I think we're OK as far as that is concerned and don't need to worry
about upgrading or anything. (BTW, there is a 5.0.2 or 1.0.2 available. But that
shouldn't affect the conversation here because they include the same version of
DiffMerge (albeit with a different build number).)

Could you send an email to "support" at "sourcegear.com" addressed to my attention
and include a tarball/zipfile with the information from the Support dialog (available
on the About Box). That will let me see all of your DiffMerge settings. Bring up
the dialog when you have the 2 files opened (because the dump also includes some
info on the opened files). If you want to include a copy of the 2 files, that would
be nice, but is not absolutely necessary. Then I can dig thru the dump offline and
see if there is something wrong that we haven't covered here.

thanks,
jeff hostetler

[Cat]

Thanks Jeff. Hopefully this is just user error.

[jeffhostetler]

To follow up publicly, after looking at Cat's data files and configuration information,
I found that there is a problem with the Hide Unimportant feature.

The (shall we say obscure) problem happens because the comment line prior to the "return"
statement ended with "//" and the EOL. The comment-starter/EOL combination causes
DiffMerge to think we are still in "comment" context at the start of the next line. If there
are any characters following the "//" and before the EOL, the problem does not happen.

To make matters somewhat worse, when in this state there can be one or more blank
lines between the comment line and the return statement and the problem still happens.

I'll have a fix for this in 3.4 (but I don't have a date for that yet).

jeff

15167

[eliad]

Hi,

i've encountered a similar problem.
when commenting-out a block (c-style) only the opening of the comment is marked as important change.
attached a test case.
maybe it's the same root cause.

thanks,
eliad.

[jeffhostetler]

That's actually a slightly different issue. The beginning of the "/*" is treated
as a main-line context so that it'll stand out when it appears opposite regular,
main-line context. We then treat the changes following the "/*" as unimportant.

For example, if we had

abc = def + ghi;

vs

abc = def /* + ghi */;

I'd want to see the initial "/*" highlighted because there was a significant
change in the line. Whereas if it was

abc = def /* + ghi */;

vs

abc = def /* + ghi + jkl */;

I wouldn't care that the contents of the comment had changed.

jeff

[paulmarchant]

Having recently been bitten by this nasty comment bug, I don't want to suffer it again. If 3.4 isn't imminent, could a version of 3.3.0 with just this fix be released?

Paul.

[jeffhostetler]

sorry, i understand the frustration.

i currently don't have a release date
set for 3.4. i'll have to check on maybe
doing a 3.3.1 with this, but I don't think
it would be until later in the summer at
the earliest.

sorry.
jeff