I'm investigating switching from Eclipse Scala IDE to Intellij 15 + Scala plugin.
I can see that compile errors are reported in the Messages tool, but I can't see any highlighting of source files containing errors in the project tree.
Is this feature not available? If not, how do you cope? Have I been just spoiled by Eclipse and should learn to 'rough it'?
Update
This question is different to IntelliJ - show where errors are because:
This question is concerned with visual indicators against files in the folder/file tree view.
That question is concerned with indicators within the files being edited. This can be seen in the accepted answer, where the screenshot concerns editor settings for code highlighting.
I opened an issue with the exact same request when I switched from Eclipse to IntelliJ: https://youtrack.jetbrains.com/issue/IDEA-110767 !
After a while you become accustomed to look at the messages window where you get active links which when clicked, directly take you to the error.
Having syntax highlighting in the tree is nice when you refactor and hence tend to break a lot of existing code. At the same time automatic refactoring was (still is?) much better in IntelliJ than it was in Eclipse.
I use Eclipse Java EE IDE for Web Developers for most of my coding, html, css, php etc etc. Recently however I have noticed an issue where after doing a combination of "something" the display of my files completely screws up and does all sorts of weird things.
For example if I try and add a on starting to do it the characters just start going all over the place and giving me display issues like that shown in the attached screenshot.
It's a little tricky to explain exactly what's happening but eclipse basically becomes unusable as each keypress seems to do something random and mess up the page even more.
Does anyone have any idea what might be causing this? I'm using a mac on Snow Leopard with Eclipse Indigo.
Just to update this. To resolve this issue I ended up downloading the latest version of eclipse and overwriting the eclipse directing with this. I tried just doing an update but this did not work so I'm guessing I had some corrupt files or something.
The good thing about eclipse is that you have a workspace folder that is essentially separate, so if you replace eclipse you can just re-import your old workspace.
ALl seems to be working as normal so far!
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/
i'm finding suddenly that eclipse, in a java project, is underlining references to uses of other class uses ive created in the same package. for another reason i reinstalled it today and the red underlinings went away. about an hour later, they popped up again. all classes have the package membership declaration.
anyone seen this before?
My guess is that your compilation is bad for one reason or another. To remedy this I usually do the following in order until one works:
Do a project clean (this should force a compile)
Close and reopen the project.
Close and reopen Eclipse.
I hope this helps.
If you press Shift+Ctrl+T or choose "Navigate > Open Type..." you get the "Open Type" dialog for quickly navigating to a known class. When you start typing a name only the classes for which the name matches stay visible. That way you can find a class of which you know the name very quick without having to browse through the package explorer tree.
This has been working great for me up until this morning. All of a sudden for a couple of my projects I am only seeing some of the types that exist. Of course I tried the obvious steps of refreshing the projects, cleaning the projects, re-building the projects, rebuilding the projects externally, but all to no avail. It is a bit odd since the types are known in other places. If I add an import statement Eclipse does not complain that it doesn't know the type and I can Ctrl-Click through the types to get to their file. However, the type navigation knows nothing about them.
In the past when InteliJ used to do this to me I would go find its cache files and delete them forcing it to rebuild. Does Eclipse have something similar I might do (I'm an Eclipse newbie)? I am using Eclipse 3.4.2 and I have it configured to not delete files on a clean (because our actual build process puts files into the output directories that I don't want Eclipse mucking with).
Have you tried closing and reopening the project? Only types from open projects are held in memory, and the refresh occurs when you Shift+Ctrl+T for the first time on a newly opened project.
Edit to add: Ctrl+Shift+R also displays the types (along with everything else) but it also supports the Camel-case thing to find the Java types quickly.
Close eclipse and delete any .index files and the savedIndexNames.txt file in workspace/.metadata/.plugins/org.eclipse.jdt.core once eclipse is restarted it will rebuildl the entire index for Ctrl+T
try starting eclipse with the -clean flag, you can add this to your eclipse.ini which can be found in the same directory as you eclispe.exe, or if you start eclipse using a bat or shell script, add it as a startup argument, e.g. eclipse -clean.
The clean will tidy your workspace, and should force eclipse JDT to recalulate types. Ive had issue with .snap files (with seem to be created on dirty shutdowns) that seem to corrupt my workspace until I clean them up, not long ago eclipse lost the Object class!! made for some interesting errors!
I get problems like this often. I tried your solution, noticed it seemed to rebuild its search index, but I still couldn't find any of my classes. Then I took a look at the little green arrow on top right corner of that dialog, and noticed I had a working set selected which belonged to another project. I find it a little dumb that Eclipse doesn't warn you about this or anything, since this can be a very annoying little detail that one tends to forget (me at least ;-)).
Anyways, clicked on "Deselect Working Set" and bam I can find my classes again. Thought I'd add this here since others may make the same mistake.
This worked for me -
Select your project in Package Explorer
Press F5 or Right click and select Refresh
I used the "-clean" as first line in the eclipse.ini (version Juno) and worked like a charm.
I'v tried all the answers and I still had the issue. I then tried this:
I deleted the project (it's a maven project) and re-imported it. This time I made sure i check the "Add Project(s) to working set" checkbox. After that Eclipse was able to find the classes in that project.
The problem must have started because I didn't check this checkbox when i first imported this project.
By the way, I'm using Neon
(Warning: Shameless marketing ahead)
If you like this feature, you would love nWire. nWire allows, among other things, to quickly search not only for types, but for any possible Java element like method or field. It also uses a navigator view which is non-modal. After searching you can see the class associations in a very quick and easy way. Check out the video on our site.