Edgewall Software

Opened 14 years ago

Last modified 4 years ago

#4329 new defect

diff does not treat TAB as whitespace

Reported by: anonymous Owned by:
Priority: low Milestone: unscheduled
Component: version control/browser Version: 0.10.3
Severity: minor Keywords: diff review
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:


Checking the box to ignore whitespace still ends up highlighting changes from TAB to space(s).

Attachments (1)

whitespace-diff.diff (1.4 KB ) - added by Tim Hatch 13 years ago.
Diff against r4825

Download all attachments as: .zip

Change History (16)

comment:1 by anonymous, 14 years ago

Further details:

The problem only seems to occur if the whitespace changes are 'near' some real changes.

Adding a couple of lines in the middle of a block of code using tabs, then converting the tabs to spaces results in the whole block being flagged as a change.

comment:2 by anonymous, 14 years ago

Component: generalbrowser
Owner: changed from Jonas Borgström to Christian Boos

I have just checked this and it is not quite true. The ignore whitespace functionality does work but not in the way this user expected.

If the diff turns up a changed section of the file and the only changes to that are whitespace then that section of changes is excluded when the whitespace box is ticked.

However, if a block contains both whitespace and other changes the entire section is shown in the diff listing and that section may include a number of lines which only have whitespace changes.

I would expect the whitespace changes to be discarded more completely so that only the lines of the files which have non-whitespace changes are shown.

comment:3 by Christian Boos, 14 years ago

Keywords: diff added
Milestone: 1.0
Priority: normallow
Severity: normalminor

Thanks for the above explanations. Indeed, this looks like an useful thing to do, but it's not completely trivial to do (markup_intraline_changes would have to have extra logic to ignore whitespace changes).

comment:4 by Tim Hatch, 14 years ago

I just ran into this too, and after looking at it have another idea. What if when given a "changed" diff block, Trac would rediff it with all whitespace stripped to discover which lines are actually "equal" when ignoring whitespace?

comment:5 by Christian Boos, 14 years ago

Milestone: 1.00.11

/me being lazy, can you post that diff so that I can test the above idea?

comment:6 by Tim Hatch, 14 years ago

Essentially it boils down to this source text:

print "Hi!"


def x():
    print "Hi!"

My scheme would take the tokens already generated:

('change', 0, 1, 0, 2)

…and rediff each change token's data (in this case, src[0:1] with dst[0:2]) after stripping the whitespace, then replace the change token with these (of course with the line numbers adjusted). This gives something like

('insert', 0, 0, 0, 1)
('equal', 0, 1, 1, 2)

if the diff opcodes in my head are working correctly.

in reply to:  6 comment:7 by Christian Boos, 14 years ago

Replying to thatch:

…and rediff each change token's data (in this case, src[0:1] with dst[0:2]) after stripping the whitespace, …

Ok, I see. This is far more complex than what I've thought, so thanks for the clarification. I was thinking about diffs having the same number of lines only, but now I see that this can also happen in the general situation.

Well, I don't know, the solution you propose should work but could be quite costly if firing up a diff is expensive.

Also, one shouldn't ignore whitespace changes when diffing python code ;)

comment:8 by Christian Boos, 14 years ago

Milestone: 0.111.0
Owner: Christian Boos removed

by Tim Hatch, 13 years ago

Attachment: whitespace-diff.diff added

Diff against r4825

comment:9 by Tim Hatch, 13 years ago

Keywords: review added
Owner: set to Tim Hatch
Status: newassigned

See attachment:whitespace-diff.diff for a less smart method that works and is more readable. However it doesn't do the fancy (and presumably expensive) twiddling with rediffing that I originally considered, so I wouldn't be surprised if it's competitively fast.

comment:10 by Tim Hatch, 13 years ago

Hmm, after driving back from the conference I had another thought — my quick method doesn't handle blank line changes, those will still be highlighted if they're within the context diff, regardless of settings.

comment:11 by Christian Boos, 13 years ago

Just a quick comment about this comment in the patch:

# We should perhaps do the same for capitalization.

I can't think of any situation where "Ignore case change" could be useful. I'd rather like to remove this option.

in reply to:  11 comment:12 by piefel, 12 years ago

Replying to cboos:

I can't think of any situation where "Ignore case change" could be useful. I'd rather like to remove this option.

Consider languages where case does not matter. Case changes may not change the semantics of the code there, which is what the reader of the diff is after.

For someone used to Python, the sentence “I can't think of any situation where "Ignore white space change" could be useful.” may be true.

comment:13 by Christian Boos, 10 years ago

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:14 by Santosh, 9 years ago

This is annoying for xml changes as well. Whenever one checks in formatted xml, it always shows many whitespace differences despite ignore whitespace is checked. We would really appreciate if this is fixed

comment:15 by Ryan J Ollos, 5 years ago

Owner: Tim Hatch removed
Status: assignednew

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.