URGENT: Suggestion for Enhancement "On-Demand Error Highlighting+Inspections" 关注
-- Please consider this enhancement, I think it's easily feasable for the next EAP, with minimal development cost and tremendous impact on the overall quality of IDEA --
I love IDEA, partly because the Error Highlighting + Inspections is a great must-have I-can't-live-without productivity feature.
Unfortunately, my machine can't cope with classes > 2000 lines, so I set the Autoreparse delay to some huge value (99999999) in order to avoid the Source Code Parsing happening at all.
This setting is at the IDE settings level, and therefore I am not bothered to get back to the settings panel each time I edit a more reasonably-sized class => which means this wonderful feature is switched off for most of the time...
So, here are my suggestions:
At the top-right corner of the Source Code Editor, on the right hand side of the scroll bar, there is a popup menu that allows me to choose the navigation mode of my errors / warnings. (it's in the square area that shows a specific color to indicate error/warning status)
why not add the function "Do Error Checking + Inspections NOW instead of waiting for the Timer activation" ?
Why not improve this by having a turn ON/OFF automatic (timed) error parsing.
- add double-click trigger on the square area that has the popup menu, for "Analyse NOW"
- add an entry in the popup menu and somewhere in the main menu bar
- add a keyboard shortcut for fast access to these indispensable functions
I can clearly see this function in my workflow:
- when I edit a big class, I can have parsing on request, and because I expect the analysis lag, and I am not irritated anymore.
- when I edit a small class, I can switch the automatic parsing back ON, and I'm the happiest man in the world !!
I know that the parsing lag is a main show-stopper for many of us, so please consider these ideas and comment ! ;)
you should post your suggestions to Jira (http://www.jetbrains.net/jira).
Also, have you tried Alt-Shift-I in the editor? It runs the editor-defined
inspections and give results that can be worked on en-masse.
Alt-Shift-i (on my Apple PowerBook G4) works as you said, but doesn't hilight the errors/warnings in my code. It only runs inspections.
I would add a trigger: if reparse is in progress and the user double-clicks on the square,
the current parse/analysis process should be stopped and automatic parsing turned off.
There should also be some visual indication of the current state of automatic parsing.
Possibly a red colored border around the square, or maybe it could replace the (almost
completely unnecessary) "Import Popup: ON/OFF" on the status bar.
Daniel WECK wrote:
Issue added to JIRA: http://www.jetbrains.net/jira/browse/IDEA-2267
Wonderful, Thanks !
I have voted ;)
On 2005-05-27 09:02:08 -0400, Tim Haley <firstname.lastname@example.org> said:
Just replace the color block with a ?
That would be obvious enough.
That would sure help out with the annoying XML red marks all over the place.
That said, I wonder if we're just circumventing a problem, instead of
seeing if it can be properly fixed.
I agree with you about the XML case.
But please bear in mind that the main concern here is performance issues: even if JetBrainers fix the error checking code to be faster with large classes, there will always be someone to come up with a situation where he/she needs to be able to turn to feature ON/OFF on demand.
(I hear some developers have 4000 lines+ in one class...scary !! 8-|)
On-demand invocation of the error/warning checking is IMO a desirable part of my workflow if I know that having it ON all the time simply ruins the user experience.
Please vote ! ;)
Robert S. Sfeir wrote:
I thought about that. We are indeed circumventing the problem for jsp, xml, etc. during
EAP; however, I do think that there will always be massive legacy files that cause IDEA
parsing to be unbearable. Sometimes, even though it would be best to let the parsing
continue and then refactor the files/classes, we don't have the authority to do so.
This enhancement would be useful in both cases.
Legacy files and generated files, I can see. Given IDEA's refactoring capabilities, there's really no excuse for files greater than 500 or so lines in active code, unless it's a library with enormous amounts of javadoc in it.
I agree with the request, BTW.
There are legitimate reasons for having large class files (not many, but they certainly exist). It certainly seems silly for users to be punished for it. I'm not sure that the ability to turn it on and off is 'good enough', since it seems like a band aid rather than a fix.
In article <5748799.1117211451307.JavaMail.javamailuser@localhost>,
Dave Griffith <email@example.com> wrote:
Thing is, it would be very useful were IDEA able to parse a 5kLOC file
sufficiently for me to work in it. I can then take out fifty lines
here, and a hundred there, each time I have a reason to be in there.
Having the parse be all or nothing makes it less likely that I will get
the time to do anything with it.
Only 5 vote ???!!!