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.
Related
When i press Ctrl+Shift+R to open the Open Resource Dialog box, the filter box does not show most of the other resource files for example.. jsp, xml etc. it works fine with all the java files.. This is happening for only this particular java project. i have refreshed the project multiple times but still no-go. I have also rebuilt the index for eclipse under workspace/.metadata/.plugins/org.eclipse.jdt.core by deleting the index files but to no avail.
I am using eclipse Kepler version. Any help would be great..
Thanks All. Yes i had closed and opened the project many times. I have also not set any Resource filter exclusions. What i noticed was that opening any of these files for edit would set off an alert saying file was derived and would i like to edit? But on the properties for these file they were not ticked as derived but rather as Archived. So had to manually hunt for the parent folder which was making these files as derived. Also noticed that the Open Resource Dialog box has option for including Resource files "Show Derived Resources"...
This one helped me solve the problem
Eclipse treating all the files in a project as Derived
This is going to sound ridiculous...but maybe this'll help others too: make sure your file search string is correct! You may need to begin it with a wildcard (*).
I lost about 45 minutes on this as the result of user error.
I was looking for some local files named eRCaGuy_PPM_Writer.h and eRCaGuy_PPM_Writer.cpp (from my repo here). So, I pressed Ctrl + Shift + R and searched for ppm_writer, as shown here:
Nothing! It would not find those files! No matter what I did to the files it couldn't seem to find them. I tried all sorts of things. Then, I realized Eclipse doesn't have a fancy fuzzy search like Sublime Text 3, so I simply added an asterisk (*) to the front of the search, and voila! It works perfectly. Since the "PPM_Writer" part of those two file names is NOT at the beginning, I must start the search with a wildcard (*).
Now it works fine, as you can see here:
I've just added a note about this to my personal Eclipse setup and configuration instructions here: https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles/tree/master/eclipse (for my full documentation, see also the PDF and Google Drive links at the top of that page).
For some mysterious reason all the target definition files (*.target) in my plugin project became empty.
I have absolutely no clue how to fix this.
With the information provided in the question it is difficult to guess the reason.
However you can try these
Open target file in Text Editor and check the content.If the size of the file is more than zero then you can see some content here.
If using any SCM tool get the older version of these files.
You can replace the file content in local history. Right click on the file go to Replace with > Local History then choose the older one and click Replace.
I've been using eclipse for java android development for 6 months and I love the compare editor. In the last few days I have been hacking away and I think I have all my git ducks in a row, or close enough that things are clean and neat and I can find old working versions of apps.
But it seems in the last day or two, the eclipse compare editor has stopped showing diffs! i right click on uncommitted PlayThread.java and choose to compare with Commit... or HEAD or branch or anything, and no matter how similar the files might be, the compare editor shows one big white bar on its right side, and clicking to go to the next difference highlights the whole file!
I have looked through the git and compare preferences on eclipse and can't find anything that might help.
Any help getting my beautiful compare editor working for me again would be greatly appreciated!
With respect to Javascript compair showing nothing, there is a known bug.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=509820
Workaround...
Window >> Preferences >> General Tab >> Compare/Patch
Deselect checkbox next to "Open structure compare automatically"
Note the the latest EGit 5.3.0 (Feb. 2020, 8 years later) improves the right side of the compare editor, using the Eclipse -> Preferences -> Text Editors -> Show whitespace characters mentioned in Vivek's answer.
Text comparisons in Eclipse have been improved to make "Show Whitespace" work in more cases.
Also, concurrent editing of a file in a merge editor and in another editor open on the same file has been improved and works now better and even for files not in the Eclipse workspace.
Note that both showing whitespace and concurrent editing depend not only on the way EGit sets up the comparison (which is what we improved) but also on the actual editors being used. These editors are beyond the control of EGit.
With files not in the Eclipse workspace, one may encounter Platform bug 214351 when a file is open in another editor.
Original answer (May 2012):
The compare editor shows one big white bar on its right side,
That means Egit considers the local content of that file (on your disk) differs completely from what have been committed.
The one classic case where that happens is for automatic eol conversion (Windows <=> Unix), which is why I always set core.autocrlf to false.
See "Git beta on Windows (msysgit) - Unix or DOS line termination".
See also "Distributing git configuration with the code" for managing those eol through .gitattribute file (except EGit doesn't support yet .gitattribute file).
In this instance, the OP mwengler reports:
Well that was it.
The way I fixed it was in Eclipse > Window > Preferences > General > Compare/Patch > General on that page I checked "Ignore white space" and now the editor shows my diffs.
But I think I will turn off that autocrlf stuff, I don't think I'm using anything on windows that can't handle both flavors
See Egit bug 361503 which mentions that this "Ignore White Space" now also honors the core.autocrlf setting.
Below setting also works for Eclipse Oxygen Release.
It appears that this has something to do with the Structured Compare. To
use the simpler and apparently working version of compare choose:
Window > Preferences > General Tab > Compare/Patch
Deselect checkbox next to "Open structure compare automatically"
Enjoy text level diffing of ES6 classes.
Regards,
Rasool Javeed Mohammad
javeed.mca#gmail.com
Today again after long I caught in this issue. Every-time I fix this problem and move on but this time I tried understanding the root cause and get it fixed and since the fix which worked for me is not in the answers to this question, thus adding part with details :
I am using EGit plugin in eclipse, and the problem was same as OP - eclipse compare tool was not highlighting the differences rather a whole block as if the whole file has changed.
Lets understand the issue first , since I was aware that this is related to CRLF vs LF eol , so went to check that first and enabled the visibility as :
Eclipse -> Preferences -> Text Editors -> Show whitespace characters
In the above click on configure visibility.
Now as you see highlighted in above image, select the check boxes under Trailing and against both Carrier Return (CR) and Line Feed (LF).
Apply - Save and Close. Now in my case , file looked like this :
and this evident that for me I had CRLF window like eol which further also confirms as I do not have core.autocrlf set to true and by default it is false thus Git actually didn't tried to do anything about my EOL delimiters (as expected in this case).
And until this stage, the compare tool was showing the whole file as changed.
Now, moving to fix which worked for me.
Since, I wanted to get this fix within IDE realm, thus I first converted the particular file to Unix delimiters as :
Then my file became with LF (Unix delimiter) eol :
And compare tool started highlighting the delta.
So the issue as it was assumed was because of CRLF (window style) eol and eclipse comparator was not able to highlight delta rather whole file.
Then, instead of changing each file or package to Unix delimiters .
I updated in Eclipse->Preferences -> Workspace
By this, eclipse takes care of line-endings for new files to Unix, so that text files are saved in a format that is not specific to the Windows OS and most easily shared across heterogeneous developer desktops. After all this compare tool worked happily ever.
Hope this helps.
So i want to format a bunch of files that i have to a certain standard. The problem is, there is A LOT of files. Is there anyway to have Eclipse open a file, hit CTRL+SHIFT+F (to format the file), save it, close it, then open the next file and repeat that process through a directory that i specify?
I don't have any experience with scripting so i have not even attempted doing something like this. I looked into plugins for Eclipse that could maybe do this but i really didn't get anywhere.
Any help is appreciated.
Thanks
You can right-click on any source folder in the Package Explorer (including the root of the project) and select Source > Format, or Source > Cleanup (which gives you even more control than a simple format)
You can right click on a folder in the Navigator or Package Explorer view and select Source -> Format. This will format all the files in the selected directory.
In one of the previous versions of one of my file in a Netbeans project I wrote code that I later removed, and now I want to retrieve it. However now I can't find it when I manually go to previous versions, as I have many versions in the local history of this file, and I don;t remember when exactly I wrote this code.
Is there a way to run a search on the local history of this file?
I saw in this answer that the local history is kept in this path
<HOME>/.netbeans/<NB_VERSION>/var/filehistory where HOME is my user home and NB_VERSION is the version of NetBeans (e.g. 7.0).
I tried running AgentRansack on that directory, but to no avail.
I recently had to solve this problem and figured it out. Netbeans stores local history files in your user directory as mentioned above. Inside that folder are numbered directories. It's pretty easy to guess which one you need based on the modification date of the folder (if you know when you last looked at it, so that doesn't help you much). In side the numbered folders is another folder with a hashed name, and inside of that folder is a set of files: a data file, and numbered files. The data file can be read with a binary file reader, and if viewed in ascii mode will show the filename that this history belongs to. The numbered files are actually zip files and they have full versions of the file in them. Just unzip those and open with a text editor if they are plain text files.
Hope this helps you out, but I realize its probably too late now. I had to figure this out because I had opened a remote file with netbeans (a file that was not associated with a project), and couldn't get back into the Local History because the file didn't have a project. However I could see it in the Local history by reading the data file, and I just guessed that the other files were zipped by the fact that they started with "PK" in the binary viewer. Once I put it all together I was home free.