I started using Eclipse Kepler and I am not sure if that is at fault or some other change caused it. Strangely * is treated as a meta character (Shift-8). To get * to be printed I have to use Option-Shift-8.
For example import is bound to Shift-8 I which essentially causes the editor to be useless.
Choosing between editors did not help
I am using Macbook pro running 10.8.3
Key bindings are stored in the .metadata directory which can be found in your workspace.
I solved this issue by going to my workspace directory and opening the file
.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi
Look for SHIFT+8 and remove or comment out the enclosing <bindings/> element (I found two in my configuration).
I have seen something similar.
I used Kepler with an old workspace, so some of my settings may have affected the defaults.
I got around the problem via the Keys preference page, where I simply used "Restore Command" for the offending key bindings.
Related
I'm using Juno on macOSX mountain lion. CMD+W doesn't close editor windows, but it gives 'put breakpoint' for some Ocaml plugins. This is strange because I can't find anything OCaml in my plugins, neither from Help->Install New Software->already installed, nor the folders in the filesystem. I must have had the plugin before but already removed it.
Preferences->General->keys shows the right binding (CMD+W means closing and NO conflict), but it doesn't work. If I change it to another binding, that will work. But CMD+W is convenient.
The weird thing is that after removing ~/Library/Cache and ~/Library/Preferences for eclipse and installing a fresh copy, the problem persists. This is what drives me crazy.
Does anybody know what is the problem? What else can I remove to set eclipse to factory default?
Thanks
I tried to use another workspace and it worked fine. So I found in my current workspace a .metadata/.plugins folder and removed that. That was the reason.
Caution: this resets everything and removes all plugins.
Previously, using the ALT+COMMAND+R key combination after highlighting a variable name in a Java file would go into the rename refactor mode. Now, the key combination replaces the highlighted text with a registered trademark symbol. How can I get the key combination to go into the rename refactor mode instead of inserting the symbol?
The current file encoding is set to MacRoman, which is the default setting inherited from container. As far as I know, nothing here has changed.
I am using Eclipse Indigo (Build id: 20110615-0604) on Mac OS X 10.7.5. Eclipse IDE for Java EE Developers 1.4.0.20110615-0550 and FreeMarker IDE SDK 1.1.0.v201006011046R-H111-GA are installed. I don't think there are any non-standard plugins.
The only recent change I can remember making is installing PyDev a few weeks ago. With the default PyDev installed, ALT+COMMAND+R opens a context menu in the lower right corner with 2 option: rename and set next symbol (this is in addition to replace the text with the symbol). I disabled the Set Next Symbol key binding in my preferences, restarted eclipse, and tried the key combo again. The text was still replaced by the symbol but the rename refactor mode was not entered did not open. I uninstalled PyDev, restarted eclipse, and tried the key combo again. The text was still replaced by the symbol.
Update (December, 2012): Another user on eclipse forums is having a similar issue: http://www.eclipse.org/forums/index.php?t=rview&goto=990973
Update (January, 2013): I have opened APSTUD-7664 in PyDev's Jira. Hopefully, a developer will pick it up and find a solution.
Same problem here (OS X 10.7.5, Eclipse Juno for Java, build 20120614-1722, PyDev recently installed). The following solution worked for me:
Eclipse > Preferences... > General > Keys
Choose Rename - Refactoring (Category: Refactor - Java)
Click Unbind Command
Click Binding field and type Command-Option-R
Click OK
A possible clue as to what's going on (I don't know): the User column is set to "C" before fixing the binding, and set to "U" afterward.
Ed's unbind/rebind trick didn't work for me, but changing "When" from "In Windows" to the more specific "Editing Java Source" seems to have done the trick.
I guess it's a bit more restrictive, but for my workflow Java is really the only place I'll be doing any refactoring.
If anyone is still having this issue (and it is still an issue with the most recent Eclipse Kepler when you install PyDev), this is the solution that worked for me. It's very similar to Ed's, but I had to unbind on the PyDev command specifically.
Go into Preferences > General > Keys menu:
Filter by the word "refactor" in the filter box. What you'll see is that there's a conflict ("C" in user column):
You need to sort by the highlight the Rename - Refactoring command and sort by binding. Then remove the filter. This will show all conflicts (including the PyDev one that is fouling things up)
Click the PyDev command bound to the same key combination click "Unbind Command"
Now nothing will be bound to that key combination, so just go back up to the correct command, "Rename - Refactoring" and rebind Command-Option-R to it.
When you're finished, it will show as a User defined command (U in user column), but it will work properly in both the project menu and in the code editor. The only thing that won't work is the PyDev command that was bound to it. If you want, feel free to bind that command to an alternative key combination.
I think .. the solution is full resetting. So i do as follow.
My environment is Eclipse kepller and Mac Mountain lion.
Terminate eclipse.
Copy workspace for safety. (Maybe its useless, but for safety...)
Delete .metadata hidden folder from workspace.
Start eclipse, then you see whole new workbench without projects!
Now, import existing project from your workspace folder.
That's all. Your default rename key is restored. And you have refreshed environment.
It's simple.
Have a nice development time.
When I launch Eclipse it starts with one of the workspaces I created and selected "don't ask again" (standardly, Eclipse asks about which workspace to start with during the startup).
So it must store somewhere which workspace to use. Where does it store this piece of information?
In
$HOME/.eclipse/org.eclipse.platform_3.7.0_155965261/configuration/.settings
there is a file
org.eclipse.ui.ide.prefs
where it is stored.
With Eclipse Juno, I can see this information in:
eclipse\configuration\.settings file.
I guess you are looking for RECENT_WORKSPACES and SHOW_WORKSPACE_SELECTION_DIALOG vars.
The settings have changed since this question was posted, as newer versions of Eclipse have been released.
With Eclipse Luna, navigate to $ECLIPSE_HOME/eclipse/configuration/.settings and the file org.eclipse.ui.ide.prefs contains settings like this (Windows file configuration shown):
MAX_RECENT_WORKSPACES=5
RECENT_WORKSPACES=C\:\\src\\eclipse-workspaces\\luna\\MyApp\nC\:\\src\\eclipse-workspaces\\luna\\MyOtherApp
RECENT_WORKSPACES_PROTOCOL=3
SHOW_WORKSPACE_SELECTION_DIALOG=true
eclipse.preferences.version=1
Each entry in RECENT_WORKSPACES appears to be delimited by \n with no spaces. Whenever I manually shuffle my workspaces around (which is rare, but it happens), I've had great success hand-editing this file, saving it, and having the new paths show up just fine in the Workspace Lancher/Select a Workspace dialog.
You have eclipse configuration files in "eclipse_home"/configuration and the one you may looking for is in settings directory : org.eclipse.ui.ide.prefs
I was facing an issue with Spring Tool Suite 4. The workspace used to give an error and I wasn't able to select other workspace also. With the help of some answers already given, I could locate the configuration in $ECLIPSE_HOME\sts-4.7.1.RELEASE\configuration.settings\org.eclipse.epp.mpc.ui.prefs
I removed RECENT_WORKSPACES property (after you try to restart, it adds default entry again) and changed
SHOW_WORKSPACE_SELECTION_DIALOG=true
STS started showing workspace selection dialog again.
If Eclipse has been installed with ubuntu-make, the file location is ~/.local/share/umake/ide/eclipse-jee/configuration/.settings/org.eclipse.ui.ide.prefs.
When I select a folder in the Eclipse Project Explorer, the 'explosion' often will cause a file to 'moved' out of its current folder - sometimes even to another project - causing errors in the re-compilation (thankfully).
Does anyone have a solution to this 'tenderness'? (If relevant, I am using Ganymede under Eclipse 3.4.2 with the Android Plugin.)
My theory is that the OP is accidentally doing a drag-and-drop and moving files. I couldn't see a simple way to turn off drag-and-drop in the preferences editor.
I worked On Eclipse Ganymede in Linux
I think there is problem with your Setting of editor
I work with Eclipse a lot, I've used Ganymede for over a year under Linux and sometimes Windows, and neither I nor any of my colleagues have ever seen such a problem.
My guess is that there are problems between your mouse and display drivers, i.e. you are inadvertently clicking on other things when you are meaning only to explode. Can you try opening folded branches by selecting the item and hitting the + key rather than clicking in the GUI?
I'm working with Eclipse Version 3.2.1 Build M20060921-0945 on a MS-Windows 2000 SP4 using a JDK 1.5.0-12.
I takes my locale that is es-AR and sets all menu and context in Spanish which I don't like. So I had included in eclipse.ini file one parameter "-nl en".
Since that, "References..." feature in both "Search" and contextual menu stopped working. I removed parameter and ran eclipse with "-clean" but still not working. I don't have any other clue about what is happening. Thank you all in advance.
Beto
Delete all the files in you eclipse data, eg:
<WORKSPACE>/.metadata/.plugins/org.eclipse.jdt.core
This should force eclipse to rebuild its index
Had the same trouble with the latest Indigo release of Eclipse, searching for references of a method or class I selected invariably gave 0 results.
Stopping Eclipse, deleting all files in folder <WORKSPACE>/.metadata/.plugins/org.eclipse.jdt.core, and restarting Eclipse afterwards has solved it.
I see a similar problem where search for references (Ctrl + Shift + G) stops working. It works again if I restart Eclipse, but it's still pretty annoying. I'm thinking maybe there's some keyboard shortcut that I hit sometimes by accident that messes up the search.
Go to {workspace}.metadata.plugins\org.eclipse.search and clear the History section of dialog_settings.xml , worked for me.
After trying all of the above and nothing working, I took another look at the file name pattern I was using for file search:
*.java *.properties, *.vm, *.xml, *.xsd
I was missing the comma after .java, so Eclipse wasn't searching my .java files, it was looking for files that matched the pattern ".java *.properties".
Wow did I feel dumb dumb dumb... adding the comma fixed it! Passing along my simplistic solution in case it does anybody else some good...
Strange as it sounds, it does seem that the keyboard mapping affects this. I had mapped -H to Search in Files, and the Java search started bringing up everything, rather then actual references to the method I was searching for. ~Nothing~ fix this, including the solution above. But remapping the key to Open Search Dialog DID fix it.
I've just come to experience this behaviour with Eclipse Mars 1 Release 4.5.1.
In an specific class only. Clean and build entire workspace does not work but I've updated Maven Project containing that class [Right-click on project -> Maven -> Update Project ...] and it works now.
Hope it helps someone.
I've just come to experience this behavior with Eclipse Mars 1 Release 4.5.1.
I tried everything mentioned above but it did not help.
So I created new workspace, and imported the project and search started working again.
I was facing a similar issue in Eclipse 2019-09 R (4.13.0) on Linux Mint
One thing that worked for me (besides closing and opening Eclipse again) was to click on the search icon and then in the Show Previous Search icon on the tab and then Open in New :
Trash your install.
Then reinstall it.