Community
Participate
Working Groups
There is a potentially hlpful show whitespace characters option in the compare editor. However it only applies to the left hand pane, making detailed whitespace comparison hard.
I believe this is a pretty old issue, probably since ever (I've never seen this working in *both* panes). Simeon, please add to the list of our internal tasks to fix.
This is not unconditional. I believe the white spaces are not shown for specific types of comparisons. Sources of binary and zip files had a problem unless I misremember, maybe other type of comparisons as wel.
This could also be an egit issue or an issue for speccific text content types (like java vs txt vs xml et).
(In reply to Andrey Loskutov from comment #3) > This could also be an egit issue or an issue for speccific text content > types (like java vs txt vs xml et). It's both. It appears that somehow the "show whitespace" works in TextMergeViewer only if the item shown: 1. adapts to SharedDocumentAdapter, and 2. that adapter's getDocumentKey() returns an IEditorInput. EGit's "Compare with Index" implements (1), but fails (2) for the (editable) index item, so whitespace characters are not shown for that item. That should be corrected. Other EGit git-based items (Compare with Previous/arbitrary revision) do show whitespace since EGit implements both (1) and (2). Xtext's DefaultMergeViewer actually replaces the items to be compared by corresponding Xtext documents if there's no backing IResource. An XtextDocument does not adapt to SharedDocumentAdapter. So Xtext fails already (1) for anything that isn't in the workspace, so whitespace characters are not shown. This affects _all_ Xtext languages that use DefaultMergeViewer. It consequently affects all EGit comparisons of Xtext resources (Compare with HEAD/Index/Previous/etc.), but there's nothing EGit can do about it. So it depends on the team provider, which should produce items for file revisions that implement (1) and (2), and it depends on the merge viewer associated with particular content types, which should maintain properties (1) and (2).
The EGit part is bug 522245.
BTW, I don't understand TextMergeViewer.createToolItems(), line 3821.[1] It says boolean needsRightPainter= !isEditorBacked(fLeft.getSourceViewer()); Shouldn't this be boolean needsRightPainter= !isEditorBacked(fRight.getSourceViewer()); ?? [1] https://git.eclipse.org/c/platform/eclipse.platform.team.git/tree/bundles/org.eclipse.compare/compare/org/eclipse/compare/contentmergeviewer/TextMergeViewer.java#n3821
(In reply to Thomas Wolf from comment #6) > BTW, I don't understand TextMergeViewer.createToolItems(), line 3821.[1] It > says > > boolean needsRightPainter= !isEditorBacked(fLeft.getSourceViewer()); > > Shouldn't this be > > boolean needsRightPainter= !isEditorBacked(fRight.getSourceViewer()); > > ?? > > [1] > https://git.eclipse.org/c/platform/eclipse.platform.team.git/tree/bundles/ > org.eclipse.compare/compare/org/eclipse/compare/contentmergeviewer/ > TextMergeViewer.java#n3821 Yep. This must be a copy/paste error. I will push a patch in a moment.
New Gerrit change created: https://git.eclipse.org/r/135137
Gerrit change https://git.eclipse.org/r/135137 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=d7e34dabfab460f62eed04eb36cbeb6f46506e03
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
(In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/135137 was merged to [master]. This suggests that an attempt has been made to fix this.