Error Highlighting in project view: It has merely just begun, right?

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...

31 comments
Comment actions Permalink

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...



0
Comment actions Permalink

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:

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...
>>


0
Comment actions Permalink

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.


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.

0
Comment actions Permalink

Yes, but if have some moduels, make will stopped after first module failed, so i will get erros hilight only in t his module.

0
Comment actions Permalink

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..

0
Comment actions Permalink

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).

0
Comment actions Permalink

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:

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...
>>


0
Comment actions Permalink

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!

0
Comment actions Permalink

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.

-


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:

>> 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...


0
Comment actions Permalink

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.

0
Comment actions Permalink

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 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.



0
Comment actions Permalink

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 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 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.


0
Comment actions Permalink

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:

Hello Stephen,

That's definetely a bug. Or it just takes too long to rehighlight the
files.

0
Comment actions Permalink

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.


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

0
Comment actions Permalink

Hello Gordon,

Nope unfortunately.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

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

0
Comment actions Permalink

"Gordon Tyler" <gordon.tyler@quest.com> wrote in message
news:19881077.1147117981375.JavaMail.itn@is.intellij.net...

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.

Yep. We use a mix of IDEA (me), JBuilder and Eclipse, and we
build using solely Ant scripts.

0
Comment actions Permalink

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.

0
Comment actions Permalink

+1

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.



0
Comment actions Permalink

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...

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



0
Comment actions Permalink

Will turning it off completely be supported in the next EAP? If not, I'm going to pass...

0
Comment actions Permalink

Excellent! :)

Ciao,
Gordon

0
Comment actions Permalink

That's not fair, you can't pass without even trying the fixed version:)

0
Comment actions Permalink

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...

Will turning it off completely be supported in the next EAP? If not, I'm
going to pass...



0
Comment actions Permalink

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:

Ant builds will be supported in the next EAP.

0
Comment actions Permalink

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...

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:

>> Ant builds will be supported in the next EAP.
>>


0
Comment actions Permalink

]]> No, and I should know that whining about it here
does not constitute a bug report.

Guy

Alexey Kudravtsev (JetBrains) wrote:

Do you have your problem submitted into www.intellij.net/jira ?

0
Comment actions Permalink

Guy Gascoigne-Piggford wrote:

<hangs head in shame> No, and I should know that whining about it here
does not constitute a bug report.


Try this: http://www.jetbrains.net/jira/browse/IDEA-6582

0
Comment actions Permalink

Ah, yes that's exactly the problem. Thanks.

Sascha Weinreuter wrote:

Guy Gascoigne-Piggford wrote:

>> No, and I should know that whining about it here >>]]> does not constitute a bug report.


Try this: http://www.jetbrains.net/jira/browse/IDEA-6582

0
Comment actions Permalink

Ok, ok, I'll try it. But it better be fabulous.

0

Please sign in to leave a comment.