Inspection UI Bugs & Enhancements (As of build 5561) Follow
This is a followup to my original post:
Inspection UI Bugs & Enhancements (As of 5.1 build 4148)
http://www.intellij.net/forums/thread.jspa?threadID=193582
I have been trying out the changes to the inspection UI,
and I am happy to see around 90% of the issues were
addressed!
I am going to resummarize the remaining issues, and also
I have some new bugs/feature requests.
Please sign in to leave a comment.
Errors Dialog
I think all of the existing issues were addressed. It is really much nicer to use now compared to 5.1.
BUG: I don't like that my inspection profilers keep getting all the new
inspections added to them by default. This is an existing issue, but
I don't think I mentioned it earlier.
I have one main profile I call "Recommended". I was looking at it
today, and I see that I have all these new inspections which I don't
care about that GWT (Google Web Toolkit) inspection, Struts Inspections,
Plugin DevKit inspections, J2ME issues, Struts Assistant, UI Form
Problems, etc.
I have another inspection I created in IDEA 4.5 (or maybe 5.0 EAP I forgot)
called "None" which is supposed to have no inspections, and it has
72 inspections enabled!
I am wondering if some of the slowness is attributable to having 72 new inspections
silently added to my "Recommended" profile?
Can't you change it so if the inspection profile doesn't contain an entry for
an inspection, that it always defaults to false?
*Useability: The filter text box doesn't respond to basic text
editing keystrokes like CTRL+DELETE to wipe out word. It is slower to delete
each character one at a time because there doesn't appear to be any delay
before the tree is refilitered. There should be some minimal delay before the
tree is refiltered like 300 ms.
Also, what does the Filter button to the right of the filter text box do
anymore now that the filter is applied in realtime as you type?
Editor (Inspection Tooltip, ALT+ENTER menu)
BUG: I keep having this problem off/on where I am looking at an inspection item
in the results tree, I will click it to jump to it in the Editor, then in the
Editor I will attempt to press ALT+ ENTER to access the quick fix, but the menu
entries will be missing! If I then move my mouse over the line to get the
tooltip to appear (sometimes have to do this a couple times), then usually
hitting ALT+ENTER again will show the menu items. This has been an annoying
problem and significantly reduced my pleasure. Anybody else seen this? This is still
happening in 5561 for me. It is easier to get it to happen if you jump from the
Inspection Results, esp. if you don't mouse over the warning in the Editor first
to cause the warning tooltip to popup. Intermittant but frequent.
Please see attached files for an example.
Attachment(s):
5557_missorted_modifiers_tooltip.png
5557_sort_modifiers_missing_from_intention_menu.png
Inspection Results Panel
-
Feature - Would it be possible to show the results as you find them,
similar to when you do a search? Some of these inspection take hours to
run, and it would be better if I could look at them sooner rather than
later.
Feature - You don't have the option to suppress for statement, suppress
for class, etc. i.e. the same options that are accessible from the
inspection's intention menu (ALT+ENTER). The Supress icon should popup a
little popup menu showing the possible choices. Also, the text in the
content pane that has the link "Suppress for method" could have the other
choices there too.
Feature: For some inspections there is a need for them to have one or
more code pointers associated with them. For example, when it says
variable is already defined in the scope, it would be nice if there was a
way to jump to where the other variable is defined, because sometimes it
isn't obvious in a large method. Another example, is the duplicate string
literal.[AlexL,no jira #]
- Bug: If you press Suppress toolbar button, and the file is read-only, it
pops up a dialog. If you cancel that dialog, the item is removed from the
tree. It should be left as is.
(There was a related Jira issue Inspection panel:
Accept then cancel resolution => inspection result (Jonas Kvarnstrom) removed
anyway http://www.jetbrains.net/jira/browse/IDEA-5631 )
Useability - I like the addition of a toggle "Filter Resolved Items" in
the toolbar. However, it doesn't work like I hoped it would.
- If you have the filter on, and then resolve some items, and then decide
you want to see the resolved items, turning the filter off doesn't bring them
back. The resolved items are only preserved if you have the filter off.
- The resolved items have the word ]]> appended to them. This is not
very noticeable, and it many cases the text is truncated. I would rather
have the item text Strike-out.
Even better, you should all the user to choose how the resolved items are
displayed by adding a new style 'resolved items' in the Colors & Fonts
settings dialog. You could also display it on the Errors settings dialog
also.
Then, if I want Strike-out text, you got it. But if someone else wants
the background color to be a different color, they could do that too.
- I would like to be able to hit DELETE to manually resolve an item, similar
to how you can do with the Find Results.
(Please see the example screenshot which shows how a search result item is
changed to foreground gray with Strike-Out text after I manually cancelled
it by pressing the DELETE key).
Useability: After I apply a quickfix, if it caused the line number to change, then
it causes the result item to change to INVALID, and you can no longer click
on it.
It would be so much better if the original text was preserved and instead you
added wavy red lines or something to indicate it was INVALID. (Again, the
style could be customized in Colors&Fonts, call it "Invalid Code Pointer" or
something.
Even if it is INVALID, I should still be able to click on it and IDEA should make
a best effort to jump the the file and line number. If the line number doesn't exist,
jump to end of file. If the file doesn't exist anymore, popup an error message or
do nothing.
(See related "IDEA Find Usages and Find in Path should make best effort
to jump to source for INVALID items"
http://www.jetbrains.net/jira/browse/IDEADEV-2610)
Cosmetic: Why do you show the "(Read-only)". Shouldn't you should the
document icon with the lock decoration? I find all the "(Read-only"
jarring to the eye, and inconsistent.
Add toolbar icons 'Group By Package', 'Group By Class', 'Group By Method'
so user can control how nested the results are. (No Jira#, AlexL)
The Inspection Results Tree can be six levels deep! For example:
Category->
Inspection Name->
Package Name->
Class Name->
Method Name->
Item
For many purposes, it might be ok to Remove the Package, and/or Class, and/
or Method grouping levels to create a flatter tree that is easier to
navigate. I find I spend alot of time opening folders!
(Related Jira Request IDEA-3832, Thomas Raugust)
Attachment(s):
5557_example_of_strikeout_text_for_manually_resolved_item.png
Inspections
-
+ Most of the new inspections added were too generic sounding, e.g. "Struts
inspection", and had very sparse documentation. Is there a reason why these can't
be broken down into specific inspections? I really can't tell what many
of these new inspections do from the name or the documentation.
Alot of work needs to be done for these to have the same quality
as existing inspections.
- Faces Model Inspection. This is very generic. The description says '
This inspection checks for JSP problems.' Hopefully the description is
going to be expanded before release. If possible, it would be better to
break it down into multiple inspections so that user has more control over
what is being checked.
- GWT Issues. This should be renamed to Google Web Toolkit (GWT) Issues.
GWT is not well known, so I think it is better to show the fullname,
because most people won't use this and it will be more obvious it can be
disabled. The GWT Issues is enabled by default.
- Struts Assistant
- Struts inspection
- Tiles inspeciton
- Validator inspection
Again, these are very generic names. Hopefully, more details will be
added and/or breakout into specific named inspections.
+ I would be nice if the new inspections were hilighted in some way, or
if there was some way to filter the inspections by release 4.0, 5.0,
6.0+. This is helpful for somebody like me who has already waded through
all the inspections and selected the ones they want. Now, I would like
to try out the new inspections, but there are so many inspections it
is hard to keep track of which are new and which are not.
Anything to help manage the massive inspection set is good, and here's one feature I would find helpful. Give each inspection a toggle that I can set to on I decide I like the inspection and its settings, whether on or off. So, I can work my way through them over time and in whatever order and finally know I'm done when all have the "this is the setting I want" toggle on. Also allow me to filter the inspection list by the toggle.
Maybe give inspections a way to tell you when (or version #) they were added and when (or version #) they were last updated?
Hello Alex,
Thanks for your attention again :)
When somebody writes a new inspection he (or she) should specify would it
be enable by default or not. The default value for this property is false
;) I mean that plugin developers should use it accurately. I don't think
that we should deny such possibility. May be just ask not to use it too often.
Esc is working.
Will fix it after beta will release.
Thank you
-
Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
Hello Alex,
It is the problem with the entire highlighting :( Quickfixes are available
(roughly) after daemon stops analyzing ...
Thank you
-
Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
Anna Kozlova wrote:
>> * BUG: I don't like that my inspection profilers keep getting all the
>> new
>> inspections added to them by default. This is an existing issue, but
>> I don't think I mentioned it earlier.
This is not (only) a plugin-related issue. There were literally dozens of new
inspections added in Demetra and even in 5.1 (that actually deserve to be on by
default to be recognized by the user), but if I have an Inspection Profile
called "JavaDoc only" that should tell me about JavaDoc problems, I want the
profile to be stable, no matter what fancy new inspections are added.
This hasn't caused me big headaches yet, but it's annoying anyway. It should be
possible to "lock" a profile against newly added inspections.
Sascha
Hello Sascha,
I don't want to lock users profiles by default. But optionally it make sense.
I agree with you.
Thank you
-
Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
>>> * BUG: I don't like that my inspection profilers keep getting all
>>> the
>>> new
>>> inspections added to them by default. This is an existing issue,
>>> but
>>> I don't think I mentioned it earlier.
>> When somebody writes a new inspection he (or she) should specify
>> would it be enable by default or not. The default value for this
>> property is false ;) I mean that plugin developers should use it
>> accurately. I don't think that we should deny such possibility. May
>> be just ask not to use it too often.
>>
Hello Anna,
I created http://www.jetbrains.net/jira/browse/IDEA-8459 for this.
Sascha
Hello Sascha,
Thanks.
-
Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
>> I don't want to lock users profiles by default. But optionally it
>> make sense. I agree with you.
>>
Hello alex,
Fixed, thank you.
Alex wrote:
I've also had some problems with this, although I mostly noticed it in
the other direction: New inspections turn up now and then, and since
they are turned off by default they are hard to find in the complete
list of hundreds of old and new inspections. For example, I have a
profile where I initially added ALL inspections and incrementally turned
off those that turned out to be too intrusive or didn't fit my
programming style, and now I don't know whether an inactive inspection
is new or was explicitly turned off.
A couple of potential ideas (though neither idea is perfect):
1) Three different configuration states for inspections: On, off and
undetermined. All new inspections would default to undetermined -- this
would mean they aren't applied, but they are shown differently in the
list so that you could easily find them, and now and then you can check
your profiles to decide whether they should be on or off.
2) Sorting inspections by date of addition -- then you could more easily
check the latest inspections to be added.
Maybe new inspections should be automatically added only to the default profile.
Maybe new inspections should be automatically added only to the default profile.
Anna> It is the problem with the entire highlighting :( Quickfixes are available
Anna> (roughly) after daemon stops analyzing ...
When this happens, there is no background daemon runnins as far as I can tell.
I had the problem happen again today. I left the Editor alone for 1 minute, and
then 5 minutes, and the problem still existed. The tooltip said
"Missorted modifiers final static" but there was no quickfix in the intention menu.
New Jiras filed for the new items above.
IDEA-8605 Inspection Results - INVALID items should not preserver the item's label and also make a best effort to jump to the source
http://www.jetbrains.net/jira/browse/IDEA-8605
IDEA-8489 Inspection Results - "Filter Resolved Items" issues
http://www.jetbrains.net/jira/browse/IDEA-8489
IDEA-8488 Inspection Results - If suppress action fails due to file being read only/user cancels, the inspection result is removed from the list even though not resolved
http://www.jetbrains.net/jira/browse/IDEA-8488
IDEA-8487 Inspection Results - Add capability for inspection results to have code pointers associated with them, e.g. for "variable is already define din the scope", etc.
http://www.jetbrains.net/jira/browse/IDEA-8487
IDEA-8485 Inspection Results - Only offers suppress for method, need to also have suppress for statement, suppress for class, suppress all inspections for class
http://www.jetbrains.net/jira/browse/IDEA-8485
One other big item I forgot to mention again was:
IDEA-6910 Support for Dual Core: Inspect Code should run in the background
http://www.jetbrains.net/jira/browse/IDEA-6910
I realize this might be post-Demetra, but this is really important as everyone gets Dual-Core and eventually Quad-Core workstations....
Ideally, Inspect Code should behave like Find in Path. The Inspection Results panel immediately appears and starts populating results as it finds them. And the status bar displays the progress of the operation. No modal progess dialogs.
+100. This should apply to all modal dialogs. grrrr.