Community
Participate
Working Groups
Eclipse 3.2M5 on Mac OS X 10.4.5 on G4 CPU with English set as language via System Preferences:International. Previous to 3.2M5 if I double-clicked on a "word" (identifier, keyword, comment, etc.) the whole word would be selected/hilited immediately. With 3.2M5 I noticed that occasionally a double-click on the middle of a word will select/hilite from the beginning of the word (on the left) to the where the cursor is located, then a fraction of a second later it selects to the end of the word (on the right). This is vexing, since I'm used to pressing Cmd-C to copy the moment I see hiliting occurring after a double-click, and now I'm only copying the first half of the word... with bug #68069 fixed I'd been looking forward to flawless cut & pastes, and now this :-P
*** This bug has been marked as a duplicate of 5138 ***
Too fast - not a dup.
Where do you see this? In dialogs and/or wizards and/or Text editor and/or Java editor? Can you provide some concrete steps to reproduce? André, do you see this too?
I've only seen it in the Java editor so far, but I haven't done much in the other editors lately. I haven't noticed it in any dialogs or wizards. I'll keep an eye out for it. Unfortunately it's sporadic and I haven't found any steps to reproduce it. I'll report them if I do. The last few times I noticed it I was doing some manual refactoring. I had a one Java source file open in one window on one monitor that I would cut text from, then move to a different Java source file open in another window on my other monitor (I'm using two monitors) and paste. The method parameters had different names in the different methods, so the parameter name errors in the pasted code would get syntax hilited. I'd double-click on the correct parameter names in order to copy and paste them into the pasted code, and occasionally I'd see the weird selection behavior. I have the Java:Editor:Mark Occurrences prefs enabled for all the elements listed, and "Keep marks when the selection changes enabled", so that hiliting is occurring also.
Ok, I just went and read bug #5138 and bug #22880, and I think it's the new functionality from 22880. When I use 3.2M4 I can: - almost double-click, i.e. mouse down, mouse up, mouse down quickly. No selection occurs. - immediately move the mouse a couple of pixels (not even a whole char) of the word I'm trying to select while continuing to hold the mouse down. The letters I've dragged over get selected. - stop dragging and mouse up. The word gets selected. When I use 3.2M5 I can: - almost double-click, i.e. mouse down, mouse up, mouse down quickly. The word gets selected. - immediately move the mouse a couple of pixels (not even a whole char) of the word I'm trying to select while continuing to hold the mouse down The selection changes from the whole word to the beginning of the word to the mouse position. - stop dragging and mouse up. The word stays at the beginning of the word to where I let the mouse up. I'm not so young anymore and my hands shake a little, so it's pretty easy for me to try to double-click but actually mousedown/mouseup/mousedown/mousemove/mouseup very quickly. 3.2M4 was forgiving and would select the word when I do this, but 3.2M5 doesn't. Naive question (I haven't looked at any of the code mentioned for 22880): any chance that a time threshold and/or a distance threshold could be added so that temporally short motions of just a pixel or two (less than a char width, but perhaps crossing the border between chars) would still register as a word double-click? Or provide the option to use the older, buggy approach? Let me know if I should create a new bug to suggest this as an enhancement, or reopen this bug, or 22880, or...
The fix for bug 5138 will fix this problem as well.
Get rid of deprecated state.
.
Changing OS from Mac OS to Mac OS X as per bug 185991
