Source tree decorations as per eclipse

This has been often discussed, and is greatly desired. The basic problem is that, unlike Eclipse, IDEA doesn't continuously recompile changed files. It only checks files for compilability and errors if you actually request such checks, or if you open the file in the editor. Thus, keeping decorations up-to-date is going to be a challenge. I certainly think there would be great value in even decorating the project tree based on the last error-analysis of each file, but can see the technical issues involved.

--Dave Griffith

Doesnt IDEA do some checking of the currently open file? If this were reflected in the tree it would go some way to the usefulness of the eclipse feature. If this is a problem then how about just marking the tab of the file somehow? This was you would be able to see problems in all open files.

I think this may be one of the reasons why Eclipse, in my experience, slows to a crawl with very large projects; it has to spend a lot of time checking the files.

I don't understand how this would be useful. Who cares which files have errors?
You find out when you compile, in a much more visible and convenient fashion.
Can you explain how you think this would help developers?

I am a long time IDEA user but recently I thought I would have a quick
look at eclipse. One of the things that I find extremely useful is the
way eclipse highlights errors in the source tree. If a file has an
error in it, then its entry in the source tree has a little red cross
in the corner of the icon. What is more, its owning package gets a red
cross and ultimately the root package also. Would anyone else find
this useful? I dont think this would take a lot of effort to implement
(:-\) but would be very useful.

Saqib

In article <192749632458834411872336@news.jetbrains.com>,
Keith Lea <keith@cs.oswego.edu> wrote:

I don't understand how this would be useful. Who cares which files have
errors?
You find out when you compile, in a much more visible and convenient fashion.
Can you explain how you think this would help developers?

You find out about javadoc errors on compile?

What about errors which you setup with custom highlighting which don't
affect compile, but you nevertheless setup as errors to get your
attention?

R

In article <17507073.1110299783046.JavaMail.itn@is.intellij.net>,
Rayz <no_mail@jetbrains.com> wrote:

I think this may be one of the reasons why Eclipse, in my experience, slows
to a crawl with very large projects; it has to spend a lot of time checking
the files.

IDEA parses all the files on startup. Not an issue here, and not a
reason for not having it. If it can be implemented in a such a way to
add information so you can fly through which files have a problem by
just looking at the tree, then +1

R

My desire for this is that it show not just errors, but warnings for the current error-highlighting profile. Having an "at-a-glance" way of seeing which files have warnings would be valuable, particularly if, for example, I could get error counts in some way (tooltip, status bar, whatever). Right now, there's no way in the product of getting a view of errors by their location, only of getting a view of errors by their error type. Not a huge gap, but a gap. Something like this would be a way to fill that gap.

I actually agree with you on compile errors, however. Since IDEA is handling all of the batch refactoring for me, I basically only see non-compilable code in the current editor window (if I've only half-typed something or my daughter has gotten to the keyboard when I wasn't looking) or if a coworker forgets to check in a file to CVS. Given my current work habits, I estimate that I see errors on compilation attempts maybe once per month. When I was starting out in software, I'd have laughed at you if you told me such a thing was possible.

--Dave Griffith

IDEA parses the files on startup (so as to speed up cross-referencing, drive the project/package view, and check for VCS/LVCS status, I've always figured), but I'm pretty sure it doesn't check for compilability status at startup, and I'm absolutely sure it doesn't run the error-highlighting stuff on startup.

--Dave Griffith

In article <28912781.1110306288775.JavaMail.itn@is.intellij.net>,
Dave Griffith <dave.griffith@cnn.com> wrote:

IDEA parses the files on startup (so as to speed up cross-referencing, drive
the project/package view, and check for VCS/LVCS status, I've always
figured), but I'm pretty sure it doesn't check for compilability status at
startup, and I'm absolutely sure it doesn't run the error-highlighting stuff
on startup.

But it could, if we chose to have that option. That would remove any
concerns about speed. Further you only need to do it once on first
project opening. The first time you check out a project and open it on
your machine. You parse all the files, check for errors etc... If a
file is never touched again, it's information is not changed. If you
change a file, then you remember, as you suggested, the last known
state, which would probably always be true. if a file gets updated from
repository, parse it. If you change highlight settings, prompt the user
and ask them if they want to update the parsing.

That said, ONLY do this after you've implemented somekind of background
parsing process, not one like the one we have now which intrudes by
popping a window up.

R

The problem is file may encounter errors or become free of errors even if
it haven't been modified. The simplest case is class deletion. Any other
class that used to use this class becomes incompilable. There are not-that-obvious
cases that may turn file to red even if there's no dependencies
with what have been changed.

-

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

In article <28912781.1110306288775.JavaMail.itn@is.intellij.net>,
Dave Griffith <dave.griffith@cnn.com> wrote:

>> IDEA parses the files on startup (so as to speed up
>> cross-referencing, drive the project/package view, and check for
>> VCS/LVCS status, I've always figured), but I'm pretty sure it doesn't
>> check for compilability status at startup, and I'm absolutely sure it
>> doesn't run the error-highlighting stuff on startup.
>>

But it could, if we chose to have that option. That would remove any
concerns about speed. Further you only need to do it once on first
project opening. The first time you check out a project and open it
on your machine. You parse all the files, check for errors etc... If
a file is never touched again, it's information is not changed. If
you change a file, then you remember, as you suggested, the last known
state, which would probably always be true. if a file gets updated
from repository, parse it. If you change highlight settings, prompt
the user and ask them if they want to update the parsing.

That said, ONLY do this after you've implemented somekind of
background parsing process, not one like the one we have now which
intrudes by popping a window up.

R

In article <c8a8a1bf5e6d8c6f240e5d178ae@news.jetbrains.com>,
Maxim Shafirov <max@jetbrains.com> wrote:

The problem is file may encounter errors or become free of errors even if
it haven't been modified. The simplest case is class deletion. Any other
class that used to use this class becomes incompilable. There are
not-that-obvious
cases that may turn file to red even if there's no dependencies
with what have been changed.

I would guess compilation would point that out in this case, in which
case the file is then parsed when it's open, and voila, reparsed. If
someone deletes a file and doesn't do a refactoring check on delete what
can you do?

R

Many of my files have many yellow warnings, and I don't care what those files
are or what the warnings are, until I'm editing that file. I don't need to
be constantly reminded of javadoc errors in files that I'm not currently
editing. I don't set custom error markings, I reserve red marks for uncompilable
code. Maybe this is why I don't think this feature would be useful.

In article <192749632458834411872336@news.jetbrains.com>,
Keith Lea <keith@cs.oswego.edu> wrote:

>> I don't understand how this would be useful. Who cares which files
>> have errors? You find out when you compile, in a much more visible
>> and convenient fashion. Can you explain how you think this would help
>> developers?
>>

You find out about javadoc errors on compile?

What about errors which you setup with custom highlighting which don't
affect compile, but you nevertheless setup as errors to get your
attention?

R

I completely agree with you, Keith. This feature seems pointless. I have never missed it even though I have used it in Netbeans and Eclipse. I'd hate to see the app size encrease for this kind of thing.

I am a long time IDEA user but recently I thought I would have a quick
look at eclipse. One of the things that I find extremely useful is the
way eclipse highlights errors in the source tree.

I'm a long time IDEA and Eclipse and for me that's one of the most annoying
"features". I always found myself opening those files "because they have
problems". I found that feature very counterproductive.
On the other hand, IDEA is letting me concentrate on the file I'm working
on. If I have thousends of files, there will be always some problems with
some of them. I could say that it's like spam, cause just highlighting them
doesn't help me to correct them until I open that file, and than, in a lot
of cases it's not that file the problem, but a reference. If I have the file
open, IDEA does much better it's job with all the inspections/hints/highilighting
- in a responsive way.
IMHO, such a feature in IDEA would be a total waste of time. It looks good
when you open an open source project for the first time, but in the day by
day work, is just annoying.

Just my 2 cents,

Ahmed.