I spend some time customizing the colors for syntax highlighting in Eclipse (Java, JSP, HTML, CSS, etc.) but whenever I try to export these settings via File|Export|General|Preferences and reimport them, the settings never completely get imported back. Some colors are restored and others are left unchanged, leaving me in an 'in between' state - very frustrating.
I'm using Eclipse 3.4 Ganymede, by the way.
Has anyone found a reliable way to save and restore Eclipse syntax highlighting settings?
I finally figured out how to do this.
I just wanted to mention beforehand that I did try to start with a fresh Eclipse install, export the preferences to a .epf file, change just one single setting, export again, and compare the files. To my surprise, trying to import settings from a minimal .epf file did not work reliably either.
The solution that worked for me was to copy these files: {Eclipse workspace directory}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs
I tried a fresh Eclipse install on another machine and after copying those files over, all my settings were restored perfectly.
The solution was to copy SOME - not all - of the files from {workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs into my other workspace.
In particular (per the https://stackoverflow.com/questions/96981/color-themes-for-eclipse thread):
org.eclipse.jdt.ui.prefs = Syntax Coloring
org.eclipse.ui.editors.prefs = Text Editors
Copying other files caused things to break.
There are a couple of notes to add:
I had to copy the aforementioned pair of files several times before I got the correct syntax coloring.
Be sure to close the workspace, if it's open in Eclipse, before copying the files.
This worked with Eclipse Helios.
If you want to be a little more fine grained on what you migrate, the syntax highlighting rules are the lines starting with semanticHighlighting on workspace-indigo/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
Doing this, I was able to migrate my syntax highlighting from Helios to Indigo
I'm using JBoss Developer Studio 10 with the Eclipse Neon 4.6 engine.
All .prefs files are inside this path:
/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings
Update: I found a similar structure on this path too:
\RedHat\JBossDev\studio\configuration\.settings
It's my IDE folder plus \configuration\.settings
I recommend search for org.eclipse.*ui*.prefs instead *.prefs to refine your result.
The principal config files are:
org.eclipse.jdt.ui.prefs
Java Syntax Color Settings
org.eclipse.ui.editors.prefs
Text Editor Settings
org.eclipse.cdt.ui.prefs
Formatter Settings
org.eclipse.wst.jsdt.ui.prefs
JavaScript Syntax Color Settings
org.eclipse.jst.jsp.ui.prefs
org.eclipse.wst.css.ui.prefs
org.eclipse.wst.html.ui.prefs
org.eclipse.wst.json.ui.prefs
org.eclipse.wst.dtd.ui.prefs
org.eclipse.wst.xml.ui.prefs
org.eclipse.wst.xsl.ui.prefs
If have a problematic workspace:
Copy the files above
Create a new workspace
Copy and Replace that files in your new workspace
This will recover perfectly your custom editors color settings. For me worked very well.
Eclipse CDT stores 'Syntax coloring' in the file org.eclipse.cdt.ui.prefs
This is located for example here: C:\eclipse\workspace.metadata.plugins\org.eclipse.core.runtime.settings\
Copy and paste over the top of the one in your new eclipse instance. This worked for me when moving from 3.4 to 3.5
I would export the preference before modifying the color, and then after.
That way, you would be able to isolate the specific rules of an eclipse preference file into one smaller file and:
check if some colors not restored are indeed represented by a rule
the import of a smaller preference has any effect on the previously unchanged settings.
That kind of strategy can be further refined into several small settings files (one for Java, one for JSP, HTML, CSS, ...), in order to better analyzing the potential side-effects when re-importing those settings.
I have had success in importing Eclipse Helios's syntax highlighting rules by copying the file:
.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
from the source workspace to the target workspace. It seems this file also contains Eclipse's code formatter profiles and code templates.
Environment:
Version: Helios Release
Build id: 20100617-1415
(on linux)
Once Michael Bosworth's answer helped me to some extend and I voted up. But now I see some obligation to answer it myself, because copying these two files are not enough. Let me explain why.
First, these files contains lines irrevelente to syntax coloring.
Second, syntax coloring for other editors are located elsewhere, for example, those of XML files are in
org.eclipse.wst.xml.ui.prefs
and those of HTML files:
org.eclipse.wst.html.ui.prefs
JSP pages?
org.eclipse.jst.jsp.ui.prefs
, etc.
Third, when we change font colors, usually we change background colors, line highlighting colors, etc. to get a clearer view of codes. This involves more files.
If we search *.pref files in path
/workspace/.metadata/.plugins
we can find all preferences files where we can locate all lines of coloring settings. But by copy-pasting all these files to another workspace can also trigger problems, for they are not exclusively syntax-coloring-related. Moreover, when we are switching between two versions of Eclipse, unexpected problems may arise.
So, the safest way is:
Create a new workspace if you don't have one.
Open all *.pref files we find in the workspace one by one,
Copy those lines containing color codes,
Find the same file in your new workspace,
Replace the color part by existing one. Or, set the colors in Eclipse, by assuming the corresponding options according to properties' name. All color codes are RGB based.
EDIT: (2017.02.24)
Eclipse Mars has a plugin Oomph, which can record your preference settings to provide seamless transmission of your preferences. When you activate it, every time you change a value, it prompts to ask you if you want to record it in Oomph, providing you the exact line in the corresponding file where your new value is stored. So, when you install Oomph, you can:
Change the settings of your font face, font size, background color, etc.
In the prompt windows of Oomph, take note of the location of your new settings. (Because if you tell Oomph to remember your settings, it will not prompt never again, so you may only see this windows once.)
I have deleted recently changed *.prefs file from the following dreictory \myworkspace.metadata.plugins\org.eclipse.core.runtime.settings\ and imported existing exported preference.
I am the first person, who answer for this question as per my knowledge :), Cause even I struggled lot.
Thanks
I faced the same problem few days ago.
The easiest way to restore the defaults is to import the default theme again, which you can find under:
http://eclipsecolorthemes.org/?view=theme&id=790
Related
I use customized syntax coloring for my Eclipse editor and it has reverted back to the default settings. This is the second time in a couple weeks that it has happened. Any ideas as to why this is happening or how I can get my custom settings back? I have a very specific coloring scheme that I like to use and it takes forever to manually set!
Are you switching across workspaces? As I understand eclipse preferences are stored in .settings/ present in workspace's root directory.
I export eclipse preferences and import it when I switch workspaces. Another cool trick I found is to close projects when I do not use them.
Eclipse official link on how to export preferences:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftimpandexp.htm
Sometimes simply import/export would not be enough, so you may need a list of .pref files where the syntax coloring settings are stored. What I have here is not complete and I just list what I use and I hope it helps.
(I process .java, .jsp, .xml, js and .properties files.)
You can find them by searching .pref files in your workspace. Remember to adjust your searching options to look into subfolders.
org.eclipse.ui.editors.prefs
org.eclipse.jdt.ui.prefs
org.eclipse.ui.workbench.prefs
org.eclipse.wst.xml.ui.prefs
org.eclipse.jst.jsp.ui.prefs
org.eclipse.wst.html.ui.prefs
org.eclipse.wst.jsdt.ui.prefs
org.eclipse.ant.ui.prefs
org.eclipse.datatools.sqltools.sqleditor.prefs
org.eclipse.debug.ui.prefs
org.eclipse.php.ui.prefs
com.adobe.flexide.mxml.core.prefs
org.python.pydev.prefs
com.adobe.flexide.as.core.prefs
com.adobe.flexide.css.core.prefs
org.codehaus.groovy.eclipse.ui.prefs
org.epic.perleditor.prefs
org.eclipse.cdt.ui.prefs
You may copy them when you finish adjusting your syntax coloring settings. When needed, search .pref again to get access to their locations, and restore your settings by copying the lines with color code, in order to avoid unpredictable side effect. As I can see this is the only way, inconvenient buy effective.
I have three common workplaces where I use the Eclipse IDE.
A nice trick when using multiple common workplaces is to copy certain configuration files to Dropbox, and link to them in the original configuration location. This way, all settings and changes are instantly available in your other workplaces.
You've got your workspace with a whopping 100 megabytes of files. You've got your .eclipse which is closing in on 200 megabytes.
I would like to know which specific files contain my custom javascript code templates, and which contains my keyboard shortcuts, so I can share these, and only these, with myself through Dropbox.
Ideally, I'd like a list of of certain settings and their locations so I can choose to share more. But I haven't found something like this on Google.
Why am I not just sharing my entire workspace and configuration directory? Well, first, it is crazy big. Second, Eclipse is modular. In some places I use certain modules that I don't use elsewhere. And you all know that modules/plugins are a crazy mess of files and configuration from which there is no escape.
You can try to export Eclipse preferences from one workspace and export them to other workspace. If it doesn't work for your, enter a bug against corresponding Eclipse project.
I figured it out.
You can copy your ~/workspace/eclipse/.metadata to somewhere. Change a preference, and sync your workspace to your backup in order to find out what files are changed.
You'll find that a lot of settings are in ~/workspace/eclipse/.metadata/.plugins/org.eclipse.core.runtime/.settings/. The javascript templates and other javascript options are in ~/workspace/eclipse/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.wst.jsdt.ui.prefs
org.eclipse.wst.jsdt.ui.prefs = Code Templates
org.eclipse.jdt.ui.prefs = Syntax Coloring
org.eclipse.ui.editors.prefs = Text Editors
I regularly open files of different types in Eclipse. For many types, Eclipse uses the system editor by default. I don't want this to happen. I want Eclipse to use the built-in Text Editor for unknown file types. However all I can find are options to set the default editor for a certain file type, but not for all unknown ones. Is there an option to do this?
I don't think you can do this in one swoop, however:
Windows > Preferences > General > Editors > File Association.
If you don't have a LOT of unknown file types, just type *.junk, *.punk, *.clunck and add Text Editor as the default editor.
Sadly you can't use *.* here.
This issue with file associations is something that has always annoyed me with Eclipse. It is specially frustrating if you are trying to use Eclipse to edit files that don't have a file extension because then you can't even set a editor.
I searched over the Eclipse bug database and found my exact issue there. It was first reported in 2003 and up until now there is no solution for it. If you follow the long comment track over the years you will see that there is no way of setting a default editor for unknown file types. From what I gathered the problem boils down to eclipse not looking at the content of file to try to determine the type. Instead it fully depends on the file extension.
Some people have made suggestions for fixes but again nothing has come out of that. If you search the bug tracker DB you will find a lot more bugs created around this.
A clean solution to this is finally implemented in Eclipse.
On the Preferences > General > Editors > File Association page, you can now define an editor selection strategy for unassociated file types.
Source: https://www.eclipse.org/eclipse/news/4.6/platform.php#text-editor-selection-strategy
There is an Eclipse plugin that overrides the default behavior of the platform and opens text file of unknown type in the plain text editor of Eclipse instead in an external editor.
https://github.com/eclipselabs/default-text-editor
I have a similar problem to this guy: Importing/Exporting Project Preferences, but my problem is worse, I need to create a new workspace (i.e. new base directory) for every program or version that I work on. I have some common preferences (formatter, font size, etc) that I have exported to a file, which I then import every time I create a new workspace, but would like to skip the step of manually importing the .epf file. Has anybody seen an easy way to automate this?
EDIT: to help potential respondents answer the question, here is my workflow for handling a bug patch. Perhaps I'm doing something wrong in general that you could correct (since I've only been using Eclipse for a couple of years and tend to prefer emacs so I haven't spent a lot of time learning new Eclipse features)?
Create new directory for the workspace.
Start Eclipse editor and open clean workspace.
Check out a CVS directory containing .psf files for the various programs (necessary because of a pre-existing CVS tree structure that does not play nice with Eclipse).
Use team import on the .psf file associated with the program I'm working on to pull in the necessary projects.
Switch all projects to the branch tag associated with the release in question.
Work...
I think that Workspace Mechanic solves all your problems.
http://code.google.com/a/eclipselabs.org/p/workspacemechanic/
copy your original workspace. Easy, reliable, but will also copy all your projects.
I often have to open a secondary editor outside of Netbeans in order to work on temporary bits of text outside of my project files. Is there a way to create temporary files in Netbeans without adding them to a project?
File -> New expects every file to be part of a project.
I know this has already been answered successfully, but there is now a proper Netbeans plugin for this requirement: http://code.google.com/p/netbeans-scratchpad-plugin/ It works nicely for me and allows multiple scratchpads which can be handy.
Also note that the Copy/Paste History plugin which is available by default (with NB7 at least) is handy for this too.
HTH,
JD
By default, there is no such feature yet (I'm using 6.5).
You could include a folder in the Favorites window, and right click > New > Empty File from the folder, it won't be part of the project.