I get files from friend who don't use netbeans IDE, when i open file that contain special caracter like 'é','à',... it show me this popup message :
if i say yes it open the file and changes those caracters to '�' like or
Any idea how to open the file safely?
The letters you are mentioning seem to be French. You need to open the file, specifying the original encoding, then save the file as UTF-8
I recently encountered a very similar problem (I have some javascript files in Chinese which translated into similar non-human readable text upon re-opening the file in NetBeans).
My OS: Linux Mint (version 17, Cinnamon; Notepad++ not available and gedit did not solve the problem).
Netbeans Version: 8.0.1
However, I was blessed to have found the history feature! I was able to get a former version of my file restored and backed it up immediately.
To access a file's history simply click on the History button found on the left side of the tool bar between the tabs of open files at the top of the IDE and the actual source code. (You can also right click on the file name and selected History -> Show History). Then Double click on a *Timestamp representing a valid version of your file. Just below the table of Timestamps the old 'backup' file and the current 'corrupted' file should appear side-by-side. (You can preview several historical versions of the file until you find one that works best for you; of course, when choosing a file I suggest one which is still usable and has the most current Timestamp associated with it!) ). Right click again on the 'backup' version of your choice -> Revert from History. Click back on the Source button found right next to the History button.
Finally, to change the default encoding, I applied the fix suggested by Sebas and Danny here:
How to change file encoding in NetBeans?
Please note that the path to the netbeans.conf file is different (at least with version 8.0.1 on my Linux machine). The path on my machine was : ~/netbeans-8.0.1/etc/netbeans.conf.
This saved the day for me and I hope it helps someone else out there! Bonne chance.
I have want seems like it should be a simple question but I keep striking out...
In Eclipse 3.8 / STS 3.1, how do I stop Eclipse from truncating the file names in the editor tabs. I can't tell which tab is which. Thanks in advance.
Try this solution.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=32789.
I have tried it with Eclipse Kepler 4.3 SR1
Under Window-> Preferences go to General -> Editors.
The last point should be "Close editors automatically", and you can specify a number.
If you check this, the least recently used editor will be closed when the given amount of opened editors is reached. That way the open editors don't take up so much space, and the possibility of truncated names is reduced.
You can always quickly search and open resources with Ctrl+Shift+R, so there is no need to have them open all the time.
Of course it can't be guaranteed to always show the complete name. If there is not enough space, what do you expect Eclipse to do?
you need to set eclipse Threme.
Under Window-> Preferences go to General ->Appearance
Threme: Classic
I'm trying to abandon Netbeans as my primary code editor. One thing I like about Netbeans is how it displays file changes - see screenshot. The colored bars give the same information as svn diff. Hovering on these bars gives the option to see the diff or revert this particular change (vs. the whole file).
What other OS X editors/IDEs have a similar feature?
Bonus question: does this feature have a particular name?
UPDATE for someone finding this question later:
With the help of phatfingers's answer, I did some further research myself to find out that Netbeans and Eclipse+Subclipse seem to be the only options offering what I was looking for.
Eclipse seems to call this Quick Diff. There's a preference to diff the current version against Pristine SVN Copy.
For the record, I'm moving to some other editor anyway. Subclipse is (still) horrible to configure on OS X, and Eclipse seems quite bloated for my purposes. Also, Eclipse's Quick Diff is no match for what is in Netbeans. Netbeans colors the diff blocks in the gutter quite more clearly, and you can revert each individual change with a click.
Although many editors provide "non-quick" svn diffs, I'll probably handle my svn diffing on the command line, with eg. svn diff | grcat conf.diff.
Or maybe I'll write a plugin for some other editor. :)
UPDATE 2: I wrote a quickdiff plugin to Komodo Edit / Komodo IDE.
The Eclipse IDE with the Subclipse plugin does a nice job of that, showing you which files changed, allowing you to compare prior versions to see changes over time, detecting which changes involve conflicts, and providing visual tools that allow you to hand-pick individual changes.
I think the class of application is called a "Merge Client" or more specifically a "Graphical Subversion Client" (as you mentioned SVN).
Update: Sublime Text has Vcs Gutter and Git Gutter, of which Vcs Gutter is a fork.
I'm a long-time Eclipse user and I just now decided to try IntelliJ IDEA 9 (free edition) for Scala.
A couple of dumb questions:
How can I tell if a file I've modified has been saved?
How can I tell if I file I've saved has been checked into CVS?
I feel incredibly "exposed" to some sort of imminent danger when I don't see the familiar visual cues from Eclipse that indicate a file has been saved and/or checked in.
Thanks
In IDEA 11:
Settings->Editor->Editor Tabs->Mark modified tabs with asterisk
UPDATE
In IDEA 15:
Settings->Editor->General->Editor Tabs->Mark modified tabs with asterisk
Under Settings -> IDE Settings -> General -> Synchronization you can control when files are saved. I save files on Frame Deactivation (that is, switching to another program), and after 60 seconds of idle time.
You should also look at the Local History feature, which is a local VCS for your project, capturing all the individual edits between commits. This allows you to roll back changes that were made by the auto-save feature, which some people find unnerving at first.
If a file is modified but not saved, there's an asterisk, *, in its tab.
If a file is newer than its VCS counterpart, its name is displayed in dark blue instead of black. If it is not under VCS at all, it is shown in dark red. This goes for the editor tab as well as other places such as the Project window.
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