I am trying to move from Netbeans to Eclipse.
Minor thing bothering me is that Eclipse dosen't seem to have the kinda edit highlighting that Netbeans does.
For example, a new line is automatically highlighted as green. An edit is highlighted as blue. And this happens in an unobtrusive way on the left along with the line numbers( if line numbers are turned on).
Is this some configuration issue or does eclipse team not support it ?
This is specifically for MercurialEclipse plugin.
I'm a heavy eclipse user and as a general rule of thumb, it supports mostly everything. So problems like these are most likely solved through configuration and/or plugins.
Regarding your specific situation...
Maybe I'm not following your question but it seems you want to look at edits that happen on a file? When I do this in eclipse, I do so through the subversion plugin (Subclipse) and compare the existing file against a previous version in the repository (to compare against the team's older version of the file) or in local history (to compare against your own version of the file).
As in:
Also there is great article about this:
http://blog.firdau.si/2010/07/09/eclipse-quick-diff-see-what-changes-youve-made-since-last-checkout/
Related
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 had put two libraries on the build path of my project, and then i closed eclipse for the night. when i re-opened eclipse, and opened the same workspace, the libraries "aren't working" in that eclipse isn't doing any of the helpful things it was previously doing, like underlining bad syntax with red squigglies, reporting things that didn't get imported, etc. anyone have an idea of what happened?
Maybe you have disabled "Project->Build Automatically"?
Try Project->Clean. Perhaps the perspective has changed, e.g. from one language to another so it isn'd doing any syntax highlighting
Has anyone managed to get Vim integrated into Eclipse painlessly? I just want to use Vim for the editor while retaining the general Eclipse interface. I have tried using Eclim plugin but the editor seemed to crash more often than work (the site said that the editor replacement functionality is still beta).
On the flip side, is there any IDE which matches Eclipse's functionality—mainly the integration with SVN, ant, etc.—and is also able to use Vim?
I mostly use eclipse for SAS SCL, Java and Javascript programming and find the eclipse editor too "mouse-y".
I'd also like, in a perfect world, to use vimdiff as a diff viewer for SVN (we use TortoiseSVN) while checking for diffs or conflicts during merge etc. I admit I havent spent a lot of time trying to get these things to work. I feel guilty about spending too much time on potential wild-goose-chases while my other team members are working away at their code, perfectly content with all that Eclipse has to offer.
Edit: Just found this while desperately browsing around: Vim plugin. Any experience using this? From the claims on the site, it sounds perfect.
I've been using Vrapper for about 2 months and it works great. It is simple to install, and makes life much easier.
It doesn't integrate Vim with Eclipse, it just emulates Vim's behaviour so you don't need to have Vim installed.
EDIT:
I have been experiencing errors while refactoring methods in Eclipse (only when Vrapper was installed) so I stopped using it.
Now I'm using ViPlugin (very similar to vrapper). It works great (especially since version 2.0) and I recommend it, but it is not free (but cheap and has a trial version)
Edit
As the new post mentioned, if we always use the rename dialog to rename, it can be a work around for Varpper.
Preferences > Java > and uncheck "Rename in editor without dialog"
http://sourceforge.net/apps/trac/vrapper/ticket/96
The consensus seems summarized in that Wanted: VIM in Eclipse article.
No decent Vi plugin exists for eclipse, except viplugin which does not offer macro mechanisms.
Whereas on the NetBeans side... jvi does a killing job ;)
WOW, this is the one!
http://vrapper.sourceforge.net/home/
It just came out a few months ago, and seems much better than the other alternatives...and it is open source.
I use Viable, which is a new plugin for Eclipse providing Vi emulation. It is very similar to vrapper, but it doesn't have the same problem as vrapper with refactoring (as cysiek10 described.)
It's got some pretty cool features which none of the other Vim emulators in Eclipse seem to have (though jvi for NetBeans has a few of these) such as:
Visual block mode
External filters and commands
Command history
Window splits (love having this one!)
It is pay; however, you can try the full version for free just like viPlugin.
I never had much luck with vim integration into any IDE, be it Eclipse, Visual Studio, NetBeans, or sth else. Instead when stuck using an IDE, I just make the IDE launch a custom program: which passes the file onto vim using the client/server feature.
I.e. vim --servername SomeName --remote-{choice of how to open it: splits or tabs} {extra args like filename and +line#}
I just tried Eclim http://eclim.org/ and found it really good. I can still edit inside Vim, and enjoy most of the benefits of the eclipse IDE inside Vim (such as better omni completions).
The best thing about Eclim is we are still using the original Vim, so I can enjoy all the existing benefits (my own functions, macros, etc.) while having the extra convenience provided by an IDE.
http://vimplugin.org, which I found over the weekend was the closest I could come to a nice integration. Unfortunately when I opened more than 2 files in my IDE, it made my entire workstation unresponsive. And I didn't even use the "new process" option for the editor.
So bottom line it does seem that there is no decent integration available yet. Although with some it's close. I'm rooting for vimplugin to stabilize and I'll also some time (when I'm not eating up my employer's time like now) play some more with hte plugin to see if I can make it usable.
I tried Eclim and didn't like it at all. I ended using this plugin called "viPlugin," which actually works well enough to warrant using it every day. Here is the site for viPlugin:
http://www.viplugin.com
The big downside of this plugin is that it's not free. I paid for it, and I think it's worth it.
...is there any IDE which matches Eclipse's functionality -- mainly the integration with SVN, ant, etc. -- and is also able to use Vim?
IntelliJ IDEA has a very good VI plugin, but I didn't like it, although the plugin did it's work.
My problem was I have formed habits to use IDEA and those were harder and my experiment didn't it through. So I uninstall the plugin, and learned idea shortcuts instead.
But, is not free :(
Vrapper does the trick.
After installing Vrapper you need to remove CTRL+W key binding in Eclipse settings. Or else it keeps closing the editor when you actually meant Backspace.
It also comes with "surround" and split window plugins. Be sure to install those.
This is not 100% Vim, though. And nothing is 100% Vim except for Vim (doh!). You will find some commands missing (or you may not, depending on how "vimy" you are). But vrapper has :vim command, which opens up Vim editor with the current file in the buffer and places your cursor in the exact location in the file. This way you can continue editing from where you left off. When you're done in Vim just close the editor, and you return to your eclipse editor.
I hope this was helpful.
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
How can I view the intermediate translation done to JSP and JSPX pages by WTP? I'm getting weird syntax errors in my Problems tab of Eclipse in a project that has plenty of .jspx pages. They don't affect anything in the running application (Tomcat 6.0) and they appeared only over the last 2 weeks, after an update.
The reason why I'd like to view the output is that I'm using the Stripes framework at http://stripesframework.org and the errors disappear for a particular .jspx file after I remove the <stripes:errors /> line of that file. At the same time, the syntax errors only appeared after I did recent fresh install of Eclipse at work, but then an update of Eclipse at home shortly therafter. I'd like to see the output to determine whose problem this should be (WTP, Stripes, or maybe just me :).
Remember that this issue is somewhat cosmetic, as it doesn't affect anything functionally. It simply spams my Problems tab in Eclipse and shows the little red X icons in the project explorer.
Right now you'd have to add the separate automated tests download to do this, and only in the 3.1 branch, but it enables a "Show Translation" command through Ctrl+Shift+9. Beware that the translation generated isn't 100% the same as the server would create at runtime--it's not intended to be executed. Also, the most recent 3.0.3 builds contain fixes to the translator that should clear up these kinds of problems (NESTED variables + self-closing tags). 3.0.3 is due in November and should update cleanly into Ganymede SR1.
I've seen the eclipse JSP editor get really confused over almost nothing. You said the problem goes away if you remove the tag. Does it come back if you put the tag back? I know that Eclipse 3.3 sometimes had some issues with JSP files where opening them, and forcing a save would clear the file of error messages (I haven't tried 3.4 yet). Maybe that's what's happening to you. Other than that, do you have all the proper includes / xml namespaces defined in the files?
I'm having exactly same problem with JSP and <stripes:errors/> tag in Ganymede. With Europa, there were no errors. Now it displays a couple of weird syntax errors on the problems pane. But as Silvaran stated it's just cosmetic, since the project builds correctly and works. It's still annoying though.