I cannot find where is the option to turn off showing me compilation errors and warning "on the fly", while coding. I want it to just show me that after debug/run code try. I was looking for in project properties and view properties but cannot find it. Could you help?
While it can be turned off, I'd suggest leaving it on. You want feedback as early in the process as you can get it.
Related
One of the features I love the most about Eclipse is that is shows you suggestions for compilation errors just by hovering over the error with the mouse. For instance, if I make a class implement an interface, it'll automatically offer me to add the unimplemented methods. Or if I use a variable I haven't created yet, it'll offer me to declare it.
Is there such a functionality in Intellij? If so, how can I turn it on?
Place your cursor on the underlined part of code which shows an error, hit ALT+Enter and pop-up menu with available quick-fixes will be shown as illustrated in the screenshot below.
This also works for other types of inspections, such as warnings, not just compilation errors.
I'm using IntelliJ 13 and the Scala plugin. In one project if I make an obvious type error I get a visual indication, like this:
But I just started a new project and a similar thing is not highlighted, even after I compile.
I'm giving a presentation on some Scala code and I'd like it if the type errors highlighted like in the first one, but I have no idea where the setting is.
One reason could be that the level of highlighting is set to a lower setting. Check your lower right corner for a button which adjusts this setting with a slider. It looks like (at least to me) a policeman face :)
Another thing is that you might not have declared what additional languages you're using besides the primary one. You can configure this in the project settings.
Also if you are using a tool to build a project (like Maven for example) try rebuilding or reimporting your project.
edit: One last thing. Make sure IDEA isn'currently reindexing or running some background tasks, this really messes up code correction.
I just started using eclim (combined with YouCompleteMe), and it's great. There is one thing that's bothering me, though, and I can't figure out how to fix it. The syntax checker runs on file saves, which is good, but it shows TODOs in the file as errors. So, in the error column on the left side of the window, an error appears when there's a TODO in the file. I've searched through all of eclim's vim files, tried a couple of eclim settings (g:EclimTodoSearchPattern and g:EclimTodoSearchExtensions), and none of those fixed the problem. Indeed, it seems like eclim's :ProjectTodo and :Todo commands aren't what's causing this, because they produce a different kind of error and location list (different colors).
I'm thinking that eclim gets a list of issues from eclipse, including eclipse's task tags (which in turn are automatically generated from any TODO text), and that's what it shows. So I tried to find a way to get eclipse not to show the task tag, but that was also unsuccessful. I can get task tags to not show up in the "Tasks" view in eclipse, but I can't get them to be removed from the file itself. Any idea of what I can do here? I would really like to be able to see a real syntax error with eclim, fix it, and see the left error bar go away, so that I know I don't have any more compilation errors. I don't want a TODO to pretend that it's a compilation error.
Well, I found one way to solve this problem, though it's not totally ideal. Eclim has a "sign level" that determines what severity of message it gets from eclipse to show in the vim window. It turns out that eclipse's task tags show up as severity level "warning", so if you set the sign level to something above "warning", the task tags no longer show up. This is done with the following line in a .vimrc:
let g:EclimSignLevel = 2
It would be better if I could lower the severity on the eclipse side, so I could still see other "warning" messages. There's probably a setting for that somewhere...
I've got an error showing in the Markers panel that doesn't actually affect anything. Is there a way to officially ignore it so I can stop looking at that red x?
FWIW, the error is an XML problem:
Referenced file contains errors (http://www.springframework.org/schema/beans/spring-beans-3.0.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
applicationContext.xml
/myproj/WebContent/WEB-INF
line 1
XML Problem
And when I say that it "doesn't actually affect anything" I mean that while it may have repercussions for prod, it doesn't seem to be affecting my dev environment & builds, which is all I care about at the moment....
Turn off the validation.
Go to Window->Preferences->Validation and turn off the XML Schema Validator and the XML Validator.
If you only want to disable the validation for a single project, go to Project->Properties->Validation. Check the 'Enable project specific setting' box and then disable the XML/Schema validation.
What kind of marker is it? Java problem? plug-in problem? some other? Mostly there will be some preference which if you change to 'Ignore', builder will not generate markers for that kind of problems.
While debugging the program my breakpoint is not working, so please give me some advice so that it can work properly.
Maybe you've tried to use the breakpoint on unreachable code? Try setting your breakpoint somewhere before the point you want to reach and try stepping from there to see if the point is actually reached.
Possible Reasons could be.
1. After changes in the code you have not built the libraries properly so the breakpoint is not pointing to the right location in the code.
2. If you are putting a breakpoint in a library then make sure the library is build and is built in Debug mode.
3. Clean full environment and rebuild the project.
Open XCode preferences and in the Debugging tab, un-check "Load symbols lazily", this caught me out when I first started iPhone developement. Then again, it might be for any of the other reasons that people have already mentioned.