Community
Participate
Working Groups
I have a project checked out from SVN. I changed a line in a *.java file from: return zip.matches("^[a-zA-Z0-9- \\/]+$"); to: return zip.matches("^[a-zA-Z0-9- \\/]{8}$"); When I compared my new code to the version in SVN, the individual changes highlight is wrong. The higlighted part is old version is "\\/]{8}$" and in new version it is "\\/]+$". That is obviously wrong, since the "\\/]" part is unchanged , also the "$" is unchanged. It should be: "{8}" and "+" highlighted. This is the same if I switch from "Java Source Compare" to "Text Compare". -- Configuration Details -- Product: Eclipse 1.2.0.20090618-0904 (org.eclipse.epp.package.jee.product) Installed Features: org.eclipse.platform 3.5.0.v20090611a-9gEeG1HFtQcmRThO4O3aR_fqSMvJR2sJ
This bug is related to 271427. The issue is with org.eclipse.compare.contentmergeviewer.TokenComparator It groups tokens into these groups: unspecified, whitespaces, digits, letters and quotes. The phenomenon reported is caused by the unspecified tokens being grouped into one group. There are several possible solutions to this. A simple solution, which might not be the best one, is to treat each unspecified character as a token, this solves bug 271427 and bug 289697. I would argue it is intuitive behavior for the tokenizer. A quick-fix is this is to change line 62 in TokenComparator.java as follows; \begin{verbatim} < if (category != lastCategory) { > if (category != lastCategory || category == '?') { \end{verbatim} The deeper issue here is of course to what degree TokenComparator should take into account the semantics of the text it parses. I leave this question open.
Would it be acceptable to add an option of not grouping at all? So a single changed letter in a word would be highlighted just by itself, while the rest is left as is? For example: - descendingOrder foo + descending0rder foo In a change like this, currently the entire first word is highlighted, obscuring or the actual change. It does not really obscure, it just does not reveal as much as it could by highlighting just the actually changed letter(s).
Created attachment 236230 [details] Screenshot of problem (orange is my self-censorship) Another case with Eclipse 4.3.1 (Kepler SR-1) Even if the only change is the removed '--' at the begin of line, the space characters are also marked. (it is even much worse if put back the '--' in the first and third line, like this: --INSERT INTO C App... -- Is... then it is totally confused and shows as if the entire old block was replaced with one line (the seconds one having " App...") and then the last two lines of the old block replaced by almost all of the new block. The actual changes are again just some '--' characters removed from the begin of line (comment in SQL) (block = the about 15 lines that I uncommented in the original file))
Created attachment 276559 [details] Screenshot of compare Another example. Even if the only changes are the space char in line 1 and the "\r" at the end of line2, the code highlights a lot more. Like the space at the begin of line 2 that did not change at all. This is with a fresh install of: Eclipse Java EE IDE for Web Developers. Version: 2018-09 (4.9.0) Build id: 20180917-1800
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.
This still happens in: Eclipse IDE for Enterprise Java Developers (includes Incubating components) Version: 2020-09 (4.17.0) Build id: 20200910-1200 I'll attach two test files that contain all the examples I mentioned before. Just put them into a workspace and compare them.
Created attachment 284639 [details] file 1 for comparison
Created attachment 284640 [details] file 2 for comparison test
