Re: Re: Features brainstorming

Tor Norbye <[email protected]> Fri, 30 Jan 2004 09:00:51 -0800
Newsgroups gmane.comp.java.netbeans.modules.tasklist.devel
Message-ID <[email protected]>
On Jan 30, 2004, at 2:22 AM, Petr Kuzel wrote:

>> Stable & supported Suggestions view and PMD suggester, heavily tested
>> for keyboard usage (F12/S-F12, and rapid file switching).
>
> You both rate the same feature highest priority.

It's actually the feature I miss the most too, but I thought that would 
be kind of obvious :)

> What particular suggestions do you use most often?

For me, it was the javaparser and pmd suggesters.

> Background: some needs PMD presence (an extra parser) others
> can be derived from exiting results of background processing
> (java/srcmodel or mdr). I think that existing PMD suggestions
> should be reimplemented over existing parser results to
> get reasonable performance.

I agree - this would be ideal. But the pmd project is pretty advanced - 
they keep adding new and more clever rules. Keeping up would be 
difficult. We can certainly address the most common rules, but for 
completeness, I would really like to be able to scan my source code and 
have all the pmd rules checked - even if that's super expensive.

>>
>> To-do comments, PMD violations, Javadoc problems, missing/old
>> copyrights; perhaps Java compilation errors.
>
> You mentioned wide spectrum of suggestions. I'm surprised Tim
> have written i18n suggestions. Tim, you could integrate them into
> i18n module to share settings and logic. Start with eager module.
> Another usefull (at lest for me) suggestion type could be spelling
> suggestions.

Just a little background again (sorry, can't resist): my original 
intent with the suggestions framework was that it would be a standard 
way to communicate suggestions. As soon as it's integrated into 
standard netbeans, standard modules can start using it. So I had for 
example envisioned that the CVS module would add tasks when it saw fit 
- e.g. if you do an update, and you get a merging conflict, it would 
add a task/suggestion stating that you should merge the conflict (and 
double clicking on the suggestion would take you into the graphical 
merge).   Likewise, the user tasks module already lists tasks that have 
due dates in the next 36 hours in the suggestions window.  So my intent 
was not that all suggestions be based on a source-scan of current file 
vs project.  Also I would imagine that build errors (probably not ant 
output, but results of compiling a file or compiling a project) would 
show up here - similar in spirit to Tim's tasklist/compilers module. 
Take a look at how Studio.NET does this. And secondly I intended that 
all the utility modules, e.g. javadoc, i18n, etc., would be providing 
scanners as part of the module. Right now the tasklist/javadoc module 
heavily duplicates one of the files in the javadoc module.

-- Tor