Bug 257235

Comment 1 Dani Megert 2009-02-03 04:36:49 EST

This is in JDT.

Comment 2 Dani Megert 2009-02-03 06:59:51 EST

Back to Compare: we return different content from org.eclipse.jdt.internal.ui.compare.JavaStructureCreator.getContents(Object, boolean) but compare fails to mark them in the compare viewer.

Comment 3 Dani Megert 2009-05-21 04:22:45 EDT

*** Bug 38178 has been marked as a duplicate of this bug. ***

Comment 4 lisa.woodring 2010-01-04 12:13:35 EST

If performing a CVS compare, would it be best to simply use the CVS flags (-bt)?

It appears to me like the compare should:
* If there is a set of whitespace elements (1 or more), ignore any changes to that set.  So, multiple spaces changed to 1 are ignored.  And a single space changed to multiple would also be ignored.
* However, removing or adding the presence of whitespace should be detected.

For example:
* 'new Object()'  --changed-to--> 'newObject()'
  should be flagged, but is currently ignored
* 'Object.CONSTANT_VAL'  --changed-to-->  'Object.CONSTANT_ VAL'
  should be flagged, but is currently ignored
* 'foo() {}'   --changed-to-->   'foo()   {}'
  ignored
* 'foo() {}'   --changed-to-->   'foo(){}'
  would be flagged as a change (would be an annoying side-effect, but accurate
  unless you expand the feature to be Java aware)

Comment 5 Pawel Pogorzelski 2010-01-05 05:55:34 EST

(In reply to comment #4)
> If performing a CVS compare, would it be best to simply use the CVS flags
> (-bt)?

This would change nothing in handling string values which is why this bug was reported in the first place.

Comment 6 lisa.woodring 2010-01-06 08:18:50 EST

(In reply to comment #5)
> (In reply to comment #4)
> > If performing a CVS compare, would it be best to simply use the CVS flags
> > (-bt)?
> 
> This would change nothing in handling string values which is why this bug was
> reported in the first place.

Maybe you should give an example then...

public static final String CONSTANT = "foobar";
public static final String CONSTANT = "foo bar";
would be flagged by CVS.

However, if this is what you mean:
public static final String CONSTANT = "foo bar";
public static final String CONSTANT = "foo   bar";
would not be flagged.

Using the CVS flags (-bt) would be a lot better than the current behavior.

Comment 7 Pawel Pogorzelski 2010-01-06 08:44:37 EST

(In reply to comment #6)

I meant your second example.

Regarding -bt flag - I'm not sure we want to show different results depending on the location of the resource (local vs. CVS). Tomasz, what do you think about it?

Comment 8 Tomasz Zarna 2010-01-28 09:24:52 EST

We should present same results no matter if we're comparing against remote (e.g. CVS) or local variant. At the same time, I can imagine a situation when compare editor shows different changes depending on type of comparison being done (i.e. Text Compare vs Java Compare). AFAIK, this can be achieved by implementing ITokenComparator and and overriding the TextMergeViewer.createTokenComparator factory method. This already happens for Java files, see JavaTokenComparator and JaveMergeViewer.createTokenComparator, so I guess tweaking the comparator could do the job. However, I don't have much experience in this particular area so I might have missed something.

Comment 9 redstun 2010-07-28 05:44:45 EDT

I was just hit by this bug when I try to create patch for https://bugs.eclipse.org/bugs/show_bug.cgi?id=321092

Comment 10 redstun 2010-07-28 05:50:44 EDT

The change from "//" to "// " is ignored with compare preference "ignore white space" enabled.

This is wrong.

At least here we should recognize that previous there's no space in the String, but now we have at lease one space, it's the difference between HAVE and HAVENOT, not just a change of space amount.

Comment 11 Eclipse Genie 2019-08-18 12:42:13 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.