Error Highlighting in project view: It has merely just begun, right? Follow
As it currently stands in 5261 it is more than useless, but
rightward confusing and dangerous.
If this feature should make it, IMHO there's an absolute
requirement to highlight errors in all dependent files, too.
For example if I simply change an interface's name (by
directly typing in the editor rather than refactoring),
all implementation classes (and recursively their packages)
should become highlighted in the project view automatically.
Currently each implementation class is highlighted only
after itself is opened in the editor - which is pretty
stupid: Usually I would open it only if I already knew there
were errors, which is brought to my attention only after I
opened the file...
Please sign in to leave a comment.
Hello Stephen,
Knowning dependent files is quite a tricky (or time consuming) task when
operating at source level. Instead we rely on compilation results so if you
invoke a Make function all the files the compiler has something to say against
goes to the dirty scope and become highlighted in the project view.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
I understand that it would be very tricky. I had hoped for some magic.
Would not have been the first time I admired Idea's technical excellence.
Well, I guess developing with Idea becomes more eclipsoid now:
When I was forced to work with Eclipse I was constantly saving to get
updated info. Man, that was annoying!
Now I am hear that I should re-compile to get up-to-date info, and
what's worse to get rid of obsolete warnings.
I have a second core that is idle waiting when Idea compiles, plus
a fast disk, and machines will get even more cores and faster disks
in the future. So how about an option to constantly compile in the
background and update error info?
Maxim Shafirov (JetBrains) wrote:
>> As it currently stands in 5261 it is more than useless, but rightward
>> confusing and dangerous.
>>
>> If this feature should make it, IMHO there's an absolute requirement
>> to highlight errors in all dependent files, too.
>>
>> For example if I simply change an interface's name (by
>> directly typing in the editor rather than refactoring),
>> all implementation classes (and recursively their packages)
>> should become highlighted in the project view automatically.
>> Currently each implementation class is highlighted only after itself
>> is opened in the editor - which is pretty stupid: Usually I would open
>> it only if I already knew there were errors, which is brought to my
>> attention only after I opened the file...
>>
How are we supposed to get it to recognized the non-java files with errors like XML files since make doesn't trigger it? Not bring every one into the editor I hope.
Yes, but if have some moduels, make will stopped after first module failed, so i will get erros hilight only in t his module.
I for one would be happy if not every single property key for Struts' <bean:message> would be highlighted as "cannot resolve", because we're not using .properties files for msg ressources, but apparently the RFE to disable this check is not of importance and I'll have to live with my whole project tree looking like a sea of red waves..
Please provide a way to switch this off.
Idea just isn't clever enough to correctly parse my jsps and resolve all
references (e.g. seam variables, ids defined in ADF Faces components).
As a result my web module is always red (at least as soon as I open the first
jsp file).
I always thought that this would be a bad way, and now it has come
true... finally IDEA has one of the "major pain in the a**" that I hate
so much about Eclipse.
I even think that with constant background compilation (with a second or
more core(s) idle) won't work well... I think IDEA was always liked for
its smartness with error highlighting, without the need to (re)compile
(major improvement over JBuilder back then) - it somehow seems that
using the compiler for this doesn't work as well, maybe the compiler
simply doesn't suit this need? (You're the experts, though...)
regards,
Messi
Maxim Shafirov (JetBrains) wrote:
>> As it currently stands in 5261 it is more than useless, but rightward
>> confusing and dangerous.
>>
>> If this feature should make it, IMHO there's an absolute requirement
>> to highlight errors in all dependent files, too.
>>
>> For example if I simply change an interface's name (by
>> directly typing in the editor rather than refactoring),
>> all implementation classes (and recursively their packages)
>> should become highlighted in the project view automatically.
>> Currently each implementation class is highlighted only after itself
>> is opened in the editor - which is pretty stupid: Usually I would open
>> it only if I already knew there were errors, which is brought to my
>> attention only after I opened the file...
>>
It appears worse than this actually (although I guess it's still early days).
I made a bad XML file yesterday, which correctly appeared in the Problem Scope. I then carried out a make and the XML file was removed from the scope window. The only way to get the XML file back into the Problem Scope window was to close and reopen the file!
Hello Stephen,
That's not true. We use files with compilation errors only for bootstrap
and then incrementally highlighting them in background so obsolete errors
will go away as you fix them.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Hello Stephen,
>>
>> Knowning dependent files is quite a tricky (or time consuming) task
>> when operating at source level. Instead we rely on compilation
>> results so if you invoke a Make function all the files the compiler
>> has something to say against goes to the dirty scope and become
>> highlighted in the project view.
>>
>> -
>> Maxim Shafirov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>> As it currently stands in 5261 it is more than useless, but
>>> rightward confusing and dangerous.
>>>
>>> If this feature should make it, IMHO there's an absolute requirement
>>> to highlight errors in all dependent files, too.
>>>
>>> For example if I simply change an interface's name (by
>>> directly typing in the editor rather than refactoring),
>>> all implementation classes (and recursively their packages)
>>> should become highlighted in the project view automatically.
>>> Currently each implementation class is highlighted only after itself
>>> is opened in the editor - which is pretty stupid: Usually I would
>>> open
>>> it only if I already knew there were errors, which is brought to my
>>> attention only after I opened the file...
Hello Maxim,
>> what's worse to get rid of obsolete warnings.
That's not true. (At least not in build 5261.)
I changed the name of a method in an interface.
Build -> Make project.
All the implementation classes went red.
I changed back the name to the original one.
=> All the implementation classes stay red.
Only after I "Build -> Make Project" again or open each individual
implementation class in the editor, the errors disappear.
Hello Stephen,
That's definetely a bug. Or it just takes too long to rehighlight the files.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Hello Stephen,
>>
>>> what's worse to get rid of obsolete warnings.
>>>
>> That's not true. We use files with compilation errors only for
>> bootstrap and then incrementally highlighting them in background so
>> obsolete errors will go away as you fix them.
>>
I actually went and got myself some tea while I left the idea window
focused, so either it's really a functional bug, or the performance
itself is a bug.
Maybe it's because the interface is in a plain Java module "api"
and the implementations are entity beans in an EJB (3.0) module?
Maxim Shafirov (JetBrains) wrote:
>> Hello Maxim,
>>
>>> Hello Stephen,
>>>
>>>> what's worse to get rid of obsolete warnings.
>>>>
>>> That's not true. We use files with compilation errors only for
>>> bootstrap and then incrementally highlighting them in background so
>>> obsolete errors will go away as you fix them.
>>>
>> That's not true. (At least not in build 5261.)
>> I changed the name of a method in an interface.
>> Build -> Make project.
>> All the implementation classes went red.
>> I changed back the name to the original one.
>> => All the implementation classes stay red.
>> Only after I "Build -> Make Project" again or open each individual
>> implementation class in the editor, the errors disappear.
I've seen this thing go totally nuts by starting to re-analyze certain files after every
bloody keystroke. This has to become much, much more performant and/or more intelligent by
not eating CPU cycles that I'd need to continue normal typing. I guess this definitely
needs an option to turn it off, at least on single-core (even with HT) machines.
Maxim Shafirov (JetBrains) wrote:
Our project doesn't use IDEA's Make. We have to build using an Ant script. If I invoke an Ant target from IDEA would the compiled files be marked 'dirty'?
Ciao,
Gordon
Hello Gordon,
Nope unfortunately.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
I'll be blunt and say it outright: That's rather short-sighted. I would wager that a significant percentage of projects build solely through Ant and do not use IDEA's Make, in particular, any project which has a policy of "developer build == release build". Not allowing those users to make use of a feature such as this will just give them one less reason to upgrade.
Ciao,
Gordon
"Gordon Tyler" <gordon.tyler@quest.com> wrote in message
news:19881077.1147117981375.JavaMail.itn@is.intellij.net...
short-sighted. I would wager that a significant percentage
of projects build solely through Ant and do not use IDEA's
Make, in particular, any project which has a policy of
"developer build == release build". Not allowing those users
to make use of a feature such as this will just give them
one less reason to upgrade.
Yep. We use a mix of IDEA (me), JBuilder and Eclipse, and we
build using solely Ant scripts.
Same here, I only ever build outside of IDEA (well, or using External Tools). But not having the project-wide errors is fine by me, I never liked it in Eclipse and I don't want it now. There should definitely be a way to turn this off.
+1
Ant builds will be supported in the next EAP.
--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"
"Gordon Tyler" <gordon.tyler@quest.com> wrote in message
news:19881077.1147117981375.JavaMail.itn@is.intellij.net...
>
Will turning it off completely be supported in the next EAP? If not, I'm going to pass...
Excellent! :)
Ciao,
Gordon
That's not fair, you can't pass without even trying the fixed version:)
We have decided to 'wave away' java source files only. Otherwise there are
chances to got stuck with always-red files, like some jsps/xml etc.
I hope it will convince you to bet.
--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"
"Colin Fleming" <no_reply@jetbrains.com> wrote in message
news:22780207.1147438501849.JavaMail.itn@is.intellij.net...
Cool, I'm another one who has to use ant or builds, IntelliJ's builds
have never been able to do what we needed (actually that might have
changed but our ant scripts are so large now I somehow doubt it).
That said, we can't use the ant support in IntelliJ because we set
org.apache.tools.ant.ProjectHelper, and I guess that IntelliJ sets this
same variable and bleems our setting.
Is there ever going to be a way around this? It would be really nice to
build in IntelliJ again.
Failing that, is there some way that an external build (as a user
defined tool) can have it's output parsed so that I can jump to error lines.
Guy
Alexey Kudravtsev (JetBrains) wrote:
Do you have your problem submitted into www.intellij.net/jira ?
--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"
"Guy Gascoigne-Piggford" <guy@wyrdrune.com> wrote in message
news:e42k5g$hmq$1@is.intellij.net...
>
>
>
>
>
>
>> Ant builds will be supported in the next EAP.
>>
]]> No, and I should know that whining about it here
does not constitute a bug report.
Guy
Alexey Kudravtsev (JetBrains) wrote:
Guy Gascoigne-Piggford wrote:
Try this: http://www.jetbrains.net/jira/browse/IDEA-6582
Ah, yes that's exactly the problem. Thanks.
Sascha Weinreuter wrote:
>> No, and I should know that whining about it here >>]]> does not constitute a bug report.
Ok, ok, I'll try it. But it better be fabulous.