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