Yes - BUT it is highly problematic (perhaps even more so now in V4.3)
There is a "Diff" (if thats the engine you are using) option called "--ignore-matching-line" which takes a "regular expression" value and if that expression matches EVERY LINE of any given diff hunk (aka: change region), Diff will choose to not report those lines.
For users directly using Diff, that might (see caveat below) be OK, but for TkDiff it is as if Diff is LYING about there being no change for those lines. As long as the number of lines involved in a Left-toRight sense remains constant, TkDiff remains unconcerned. But when they do not, TkDiff gets seriously confused about what lines in each file supposedly "line-up", which in turn plays havoc with all the highlighting it tries to do. We are looking into this case to see if we can protect TkDiff from stumbling like that.
But as a further caveat, the whole concept of ignoring an entire line on the basis of an expression that might only match part of it is self defeating - even for users of just Diff itself, let alone TkDiff. Imagine a comment that trails a real code statement - which might have a real change on it. Ignoring that line equates to hiding the real change. Thus it becomes a requirement to write the regular expression to only apply to FULL lines, which limits your original goal of avoiding "changes in comments" you don't care about.
In a similar way, even the options that tell Diff to "not worry" about changes in "whitespace" are (no pun intended) "white" lies that can result in lines not being properly formatted when trying to merge code changes. Granted, most languages won't care (except maybe Python) but if you have coding standards that must be met, managing that whitespace is part of the job.
The best choice there might be to use the whitespace options when trying to make code changes, to limit what you must look at, but then to re-run one final time without them to ensure indentation is as you expect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a short note to say that as of V4.3.1 the handling of ignored lines HAS been addressed. TkDiff will now accept not only command line arguments to suppress lines (either empty or regular-expression matched), but it is even possible to preserve the specifications as preferences that can subsequently be applied or ignored as necessary. Note that all of this is a TkDiff capability (it is NOT simply a pass-though to the underlying "diff engine") which, in turn, means that it will continue to work if something other than "Diff" is chosen as the diff engine.
However, all the caveats about using it and similar features (mistakenly matched lines, indentation management) are still applicable; but TkDiff will now at least continue to function properly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am translating some source codes and fixing the code as well.
Is it possible somehow to set that tkdiff does not compare stuff in C++ comments ( single lines after double slash) ?
Thank you
Yes - BUT it is highly problematic (perhaps even more so now in V4.3)
There is a "Diff" (if thats the engine you are using) option called "--ignore-matching-line" which takes a "regular expression" value and if that expression matches EVERY LINE of any given diff hunk (aka: change region), Diff will choose to not report those lines.
For users directly using Diff, that might (see caveat below) be OK, but for TkDiff it is as if Diff is LYING about there being no change for those lines. As long as the number of lines involved in a Left-toRight sense remains constant, TkDiff remains unconcerned. But when they do not, TkDiff gets seriously confused about what lines in each file supposedly "line-up", which in turn plays havoc with all the highlighting it tries to do. We are looking into this case to see if we can protect TkDiff from stumbling like that.
But as a further caveat, the whole concept of ignoring an entire line on the basis of an expression that might only match part of it is self defeating - even for users of just Diff itself, let alone TkDiff. Imagine a comment that trails a real code statement - which might have a real change on it. Ignoring that line equates to hiding the real change. Thus it becomes a requirement to write the regular expression to only apply to FULL lines, which limits your original goal of avoiding "changes in comments" you don't care about.
In a similar way, even the options that tell Diff to "not worry" about changes in "whitespace" are (no pun intended) "white" lies that can result in lines not being properly formatted when trying to merge code changes. Granted, most languages won't care (except maybe Python) but if you have coding standards that must be met, managing that whitespace is part of the job.
The best choice there might be to use the whitespace options when trying to make code changes, to limit what you must look at, but then to re-run one final time without them to ensure indentation is as you expect.
Just a short note to say that as of V4.3.1 the handling of ignored lines HAS been addressed. TkDiff will now accept not only command line arguments to suppress lines (either empty or regular-expression matched), but it is even possible to preserve the specifications as preferences that can subsequently be applied or ignored as necessary. Note that all of this is a TkDiff capability (it is NOT simply a pass-though to the underlying "diff engine") which, in turn, means that it will continue to work if something other than "Diff" is chosen as the diff engine.
However, all the caveats about using it and similar features (mistakenly matched lines, indentation management) are still applicable; but TkDiff will now at least continue to function properly.