Bug 78063 - [Compare] Full Javadoc line selected even though only a character has been added to a word
Summary: [Compare] Full Javadoc line selected even though only a character has been ad...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M7   Edit
Assignee: Dani Megert CLA
QA Contact:
URL:
Whiteboard:
Keywords: polish
: 152977 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-11-08 06:18 EST by Dani Megert CLA
Modified: 2007-05-04 02:39 EDT (History)
3 users (show)

See Also:

Attachments
Patch to parse text in a one line comment (3.11 KB, patch)
2007-04-19 09:44 EDT, Michael Valenta CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Megert CLA 2004-11-08 06:18:56 EST 
3.1 M3

I fixed a typo (added 'i') in the Javadoc of
AdditionalInfoController2.fStartSignal (rev. 1.5). Comparing (CVS and local
history) does not select the word but the full Javadoc (from /** to */).
Comment 1 Dani Megert CLA 2006-01-10 06:03:49 EST 
Same is true for strings inside Java code: both strings are selected instead of just the change inside the string.
Comment 2 Michael Van Meekeren CLA 2006-04-05 16:39:56 EDT 
will anything be happening here for 3.2?
Comment 3 Andre Weinand CLA 2006-04-07 09:19:49 EDT 
I'll try to fix this for 3.2.
Comment 4 Markus Keller CLA 2006-08-07 11:13:16 EDT 
*** Bug 152977 has been marked as a duplicate of this bug. ***
Comment 5 Michael Valenta CLA 2007-04-09 16:37:33 EDT 
This is caused by the JavaTokenComparator provided by JDT/UI, which provides the entire body of the comment as a single token. The JavaTokenComparator uses a scanner that is created using JDT core API. It would be helpful is someone from JDT/UI could take a look at this and offer advice on how to proceed ;-)
Comment 6 Dani Megert CLA 2007-04-10 05:04:50 EDT 
The scanner does not go into comments i.e. each comment is just one token. If a comment is detected the JavaTokenComparator should go into the comment and return tokens as TokenComparator does.
Comment 7 Michael Valenta CLA 2007-04-10 10:00:21 EDT 
And how would I know it is a comment? It doesn't appear that the IScanner API provides any hint as to what the token represents.
Comment 8 Dani Megert CLA 2007-04-10 10:06:27 EDT 
See IScanner.getNextToken() and ITerminalSymbols.
  TokenNameCOMMENT_LINE
  TokenNameCOMMENT_BLOCK
  TokenNameCOMMENT_JAVADOC
Comment 9 Michael Valenta CLA 2007-04-19 09:44:02 EDT 
Created attachment 64308 [details]
Patch to parse text in a one line comment

This patch fixes the one line comment case and also adds token highlighting for portions of the text that couldn't be scanned.
Comment 10 Michael Valenta CLA 2007-04-19 09:45:23 EDT 
Moving to JDT/UI to consider patch.
Comment 11 Dani Megert CLA 2007-04-19 10:40:00 EDT 
Let me take this ;-)
Comment 12 Dani Megert CLA 2007-04-19 12:08:57 EDT 
I slightly modified the patch and committed it to HEAD.
Comment 13 Dani Megert CLA 2007-04-19 12:27:30 EDT 
Michael, using again the Java tokenizer to tokenize the comment could lead to strange results (e.g. if the comment is just code). Markus will change this to use the text tokenizer and also add code to go into strings.
Comment 14 Michael Valenta CLA 2007-04-19 13:06:33 EDT 
I was going to use the text tokenizer but it isn't API. You could either use the internal class or refactor the code so you can get it from the JavaMergeViewer superclass. Sorry but I forgot about the string case but it should be the same as the others.
Comment 15 Markus Keller CLA 2007-04-19 14:09:14 EDT 
(In reply to comment #13)
Released to HEAD and filed bug 183224 to make TokenComparator API. Falling back to  JavaTokenComparator in cases where no TextMergeViewer is available.
Comment 16 Dani Megert CLA 2007-05-04 02:39:00 EDT 
Verified in I20070503-1400.