Community
Participate
Working Groups
On Eclipse 3.1M4 (but probably not 3.1M3 and certainly not 3.1M2) on Windows XP, a Control-V sometimes causes the definition to be opened before the paste occurs. ? Is there now some kind of 'smart' hover that is causing the definition to become the context ? Yes it is 'sometimes' (perhaps 1 in a 100), hence the query as to whether there is a dynamic involved. This is obviously a really bad ergonmomic.
I'm confused a bit by this description, and I'm not sure what you're saying. As far as I know, "Ctrl+V" is only ever bound to "paste" (default key configuration) or "page down" (Emacs key configuation). It is never bound to "go to definition". Is this your own keyboard shortcut? A keyboard shortcut you've gotten from somewhere else? Or are you talking about something else entirely? Could you give really verbose steps for reproducing your problem?
No reply. Closing as WORKSFORME. Please re-open if you have more information....
I'm still seeing this, on 3.1M6 on independent Windows XP Home (my own), and Windows 2000 (my employer's) systems, with JDK 1.5.0_01. Both on standard DELL keyboards. It's highly intermittent, and I suspect dependent on subtle timing relationships between pressing "Control" and "V" keys. It would appear that JDT is responding to F3 instead of Control+V.
I closed this as worksforme because I don't understand your bug. You're going to have to help me out. Can you please answer the questions in comment #1?
I did reply to your comments, but it seems that the wonders of Bugzilla and post-reply login may have swallowed them up. I run with a very naked Eclipse, certainly no extra short cuts. Eclipse 3.1M6 + emf-sdo-xsd-SDK-I200503170700 + GEF-ALL-I20050408 Then pretty much, just change Perspective tabs to icons only, and change text search to wrap. Generally working with a PDE, CVS and Debug perspective. I cannot reproduce the problem reliably. It happens about one time in a hundred with I do Control+V in a Java edit. I'm just editing in my normal fashion, and suddenly the paste takes me somewhere unwanted, and if I'm not watching carefully I find myself editing somewhere undesirable. I cannot answer for other forms of edit because Java edit is the only Eclipse editor I make prolonged use of.
Which keyboard layouts do you have installed on your machine?
I don't knowingly have any keyboard layouts installed. I just use the standard that Dell provides in the UK, which I think is very similar to the US, though we now how a Euro sign on "4" as well as "$", though I've no idea how to use it.
Okay, just to make sure, could you go to "Control Panel > Regional and Language Options > Languages > Details..." In the "Installed services" area, could you tell me which keyboards are installed? I still don't see how "Ctrl+V" could trigger "Open Declaration". (I assume you mean "Open Declaration", as there is no "Go to Definition" command in the default Eclipse SDK.) "Open Declaration" is only mapped to "F3". If one of these extra plug-ins is contribution a "Go to Definition" could you please attach the "plugin.xml" file that is binding "Ctrl+V" to something?
I have English (United Kingdom) as default and English (United States) as well. I agree that the bug report seems stupid, but it keeps happening. It's as if Control-V presses F3 by mistake. If another plug-in was contributing, it would malfunction 100% not 1% of key presses. This perhaps suggests a need for SWT to workaround a Windows 'feature'. But yesterday I had another idea when I noticed that a particular malfunction occurred after an edit that inserted/removed lines (sorry I forget which). Could there be a race between the incremental compilation thread and the user interface thread, such that the Paste hits an unstable/invalid context and failing to find the paste target does open declaration intead? (I have Build Automatically on.)
Well, this is why I'm wondering if someone else has bound "Ctrl+V" in some other context. It's possible that some weird window manager race condition is causing the wrong "Ctrl+V" binding to get processed. Okay, what I want you to do is the following. I'd like to run with some tracing options. This will allow me to see the raw key events. You will need to create a file somewhere on disk called "options". In it put the following 4 lines: org.eclipse.ui/debug=true org.eclipse.ui/trace/contexts=true org.eclipse.ui/trace/keyBindings=true org.eclipse.ui/trace/keyBindings.verbose=true Then, open a command prompt and run Eclipse. Start Eclipse with the following additional parameter: -debug C:\path\to\options Then recreate the problem. Include the output from the command prompt. If it's not entirely clear, also add some annotations as to where certain events happened (e.g., "This is where I pressed Ctrl+V and Open Declaration happened")
The problem reproduced after I added -debug C:\Development\UMLX\PasteDebug.options to my short cut, but I can't find any obvious log file to send you. Running with -debug C:\Development\UMLX\PasteDebug.options from a Command Prompt gives no interesting output at all. Am I missing smething?
Could you try also specifying -vm "C:\path\to\jdk\bin\java"
I was already using a -vm. "Running with -debug C:\Development\UMLX\PasteDebug.options from a Command Prompt gives no interesting output at all." "Am I missing smething?" By no interesting output, I mean no diagnostic output of any kind. Where am I supposed to see some debug output? I am using: C:\Tools\Eclipse\3.1M6\eclipse.exe -data C:\Development\UMLX\Workspace3.1M6 - debug -debug C:\Development\UMLX\PasteDebug.options -consolelog -vm C:\Tools\Java\jdk1.5.0_01\jre\bin\javaw.exe -vmargs -Xmx512M in a Command Prompt (and the same with /s in a cygwin shell), but I get no debug output or console, whereas at least -debug -console and -consoleLog give me reaction when run from within Eclipse.
I meant to indicate that you shouldn't use "javaw" but "java". Try the following: "C:\Tools\Eclipse\3.1M6\eclipse.exe -data C:\Development\UMLX\Workspace3.1M6 -debug C:\Development\UMLX\PasteDebug.options -vm C:\Tools\Java\jdk1.5.0_01\jre\bin\java.exe -vmargs -Xmx512M"
It's been a bit reluctant to reappear, buit a similar mis-function logs as KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x0, keyCode = 0x40000, time = 46262687, character = 0x0) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x40000, keyCode = 0x63, time = 46262859, character = 0x3) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [CTRL+C]) KEYS >>> WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.ui.edit.copy', parameters = {}) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x40000, keyCode = 0x76, time = 46263359, character = 0x16) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [CTRL+V]) KEYS >>> WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.ui.edit.paste', parameters = {}) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x40000, keyCode = 0x76, time = 46263765, character = 0x16) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [CTRL+V]) KEYS >>> WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.ui.edit.paste', parameters = {}) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x0, keyCode = 0x61, time = 46266500, character = 0x61) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [A]) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x0, keyCode = 0x6c, time = 46266875, character = 0x6c) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [L]) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x0, keyCode = 0x6c, time = 46267000, character = 0x6c) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [L]) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x0, keyCode = 0x20000, time = 46267234, character = 0x0) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x20000, keyCode = 0x73, time = 46267390, character = 0x53) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [SHIFT+S]) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x0, keyCode = 0x40000, time = 46271328, character = 0x0) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x40000, keyCode = 0x63, time = 46271500, character = 0x3) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [CTRL+C]) KEYS >>> WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.ui.edit.copy', parameters = {}) KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x80000, keyCode = 0x40000, time = 46272593, character = 0x0) I was trying to edit editing "TypeSafeUtils.getESuperTypes(derivedClass)" in CreateInheritanceCommand.java to "derivedClass.getEAllSuperTypes()" and suddenly found myself in TypeSafeUtils.java which wasn't even open. Not even at a particulary sensible place. End of a line in mid method, and not the most recently edited method. ^C should not change edit windows. The log looks innocuous and shows no sign of an editor open. Probably need some more debug options? [Retract my theory on a race condition. When I wasn't logging I got a near- repeatable failure after I had paused to think for a while.]
The trace makes it seem like it is not a key binding issue. "Ctrl+C" triggered a copy; that's all that happened. The only options left are that it is triggering some native widget behaviour or that it is some other input device that is triggering the change. Do you have any problems with a jumpy mouse or such like?
It still happens on 3.2M6, but why is it just me complaining? Possibly related, as of ? 3.2M5, I find that the selection range can often fail: I select a range of characters, but by the time I have ^C'd the range has shortened.
Moving to Component owner PW
I have a slow motion repro for 3.2.1 and 3.2.2 but not 3.3M7 although I think I've been observing the problem on 3.3Mx too. In a Java editor -- point at whitespace -- press down control -- move cursor over definition label .... the definition label changes to blue underlined hyperlink -- double left click (intending to select definition label word) .... focus changes to definition context -- press down V (intending to paste original label reference) .... actually paste over the label definition So it's a nasty timing interaction depending on the speed at which the hyperlink appears. Ctrl-Left does not appear in the key preferences, so cannot be disabled.
*** Bug 223585 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > It still happens on 3.2M6, but why is it just me complaining? > > Possibly related, as of ? 3.2M5, I find that the selection range > can often fail: I select a range of characters, but by the time I have > ^C'd the range has shortened. I have this problem sometimes, but it's the wireless mouse that does it for me. But I can't reproduce this problem no matter how fast I do CLICK-CLICK-CTRL+V Standard PS/2 wheel-optical mouse. PW
My repro shows that it is inadveretent CTRL-CLICK-CLICK+V instead of CLICK-CLICK-CTRL+V that causes the problem. Sitting on the CTRL key when following the repro is a bad habit. Accidental mis-ordering of CTRL and CLICK is a very common 'dyslexia'. How often do you find that you occasionally reverse character ordering through mis-ordering of distinct fingers? It is an unavoidable human foible that the Eclipse bindings must tolerate.
(In reply to comment #22) > How often do you find that you occasionally reverse character ordering > through mis-ordering of distinct fingers? It is an unavoidable human > foible that the Eclipse bindings must tolerate. This sounds like a user error, not an eclipse problem ... it's the OS that determines that we must react to mouse events and keydown events ... don't hold the CTRL key down unless you want to jump to declaration. PW
*** Bug 227966 has been marked as a duplicate of this bug. ***
You can disable hyperlinking, or assign a key other than Ctrl. Window > Preferences, General > Editors > Text Editors > Hyperlinking.
https://www.eclipse.org/forums/index.php/mv/msg/1096124/1798104/#msg_1798104 identifies two other users experiencing similar problems.
This still occurs too often to be finger trouble and occasionally while I can inspect my finger positions to confirm that it is not a mis-type of perhaps Ctrl-B. A similar problem, but not the same, occurs when the debugger steals focus see Bug 476276 and forces activation at the start of the current method. Note to self, next time it happens and it's not the debugger, identify all other views that may be spuriously active. (e.g. maybe some linked View has got over enthusiastic.)
(In reply to Ed Willink from comment #27) > Note to self, next time it happens and it's not the debugger, identify all > other views that may be spuriously active. (e.g. maybe some linked View has > got over enthusiastic.) Debugger was active but execution had terminated. Type Hierarchy View is active focussed on the class from which Control-V departed. Interestingly the class has a ">" prefix in the Type Hierarchy View. Looks as if the Type Hierarchy View got improved to track "dirty". Very probably the Type Hierarchy View is failing to distinguish what it should do while passively tracking without focus to what happens when active.
*** Bug 575701 has been marked as a duplicate of this bug. ***
(In reply to Matthias Mailänder from comment #29) > *** Bug 575701 has been marked as a duplicate of this bug. *** But unlike the vague indications of this bug, the 'duplicate' has a much more precise analysis: Using CTRL + C and V regularly makes me jump into another class and wrongly paste there. This happens because hyperlinking makes use of CTRL + click. https://stackoverflow.com/questions/1380596/eclipse-jumps-to-definition-while-copy-pasting suggest to simply rebind CTRL to another modifier, but other IDEs use the same set of keys and don't suffer from the problem. It seems they simply turn off CTRL click class selection when the user drags the mouse, which avoids miss clicks. There is also Bug 575404 which focuses on the performance problem of said behavior, but it may be the same underlying problem.
Now that we have 4 duplicates and a strong explanation of how source text corruption can occur, I think this merits MAJOR.
I have experienced this sometimes, too. Always wrote if off as some mis-manipulation of mine. I can't reproduce it on purpose, though. Looking through these bugs it seems that when this occurs it's always if a double-click is used to select the word to be replaced. If so, I suspect indeed a user error: double-click but hit the CTRL of CTRL-V too early. Might be dependent on the double-click interval set. Argument against that theory: it's only ever been reported with CRTL-V, but never with CTRL-C. Still: I notice that CTRL-DoubleClick also jumps to the definition. Perhaps that should jump only on CTRL-Click. But it's unclear to me how that could be prevented.
Matthias Mailänder analysis in Bug 575701, pasted in comment 30, seems to shed significant light on the problem. As well as Ctrl-Click being significant we have Has-Moved, so potentially a one-pixel movement between Ctrl and V events may be the discriminating factor. It really is shaky hand finger trouble. I have reported a very poor Has-Moved filter in Bug 459358, Bug 489338. I cannot find the bug for another similar problem whereby when using the JUnit tool bar menu, I find it very easy to get an accidental selection of Export... when I wanted History... I think it occurs because Down activates the menu and if a fast Up occurs elsewhere, the Has-Moved detects movement and so takes a premature selection. IMHO an event within 3 pixels and 2 seconds of another event is not a movement.
16 years on, we can at least be sure that this regression is real and we have some interesting speculations regarding composite key bindings and mouse movement. (In reply to Ed Willink from comment #0) > On Eclipse 3.1M4 (but probably not 3.1M3 and certainly not 3.1M2) We also have a pretty good timeline. Given the difficulty of reproducing, it would seem appropriate for some committer who understands key binding and event dispatch to review the perhaps 10% of edits that may affect - key binding declarations - key binding processing - event creation - event splitting/merging The Bugzilla date confirms the pre-3.1M4 end stop for a review and the "certainly not 3.1M2" gives some encouragement that it is not necessary to review further than 3.0 GA. The bad edit has not been corrected, but may have been refactored in the interim.
(In reply to Thomas Wolf from comment #32) > theory: it's only ever been reported with CRTL-V, but never with CTRL-C. https://www.eclipse.org/forums/index.php/mv/msg/1111103/1853390/#msg_1853390 reports it with Ctrl-C
