Re: Source Scanner...
Tor Norbye <[email protected]>
| Newsgroups | gmane.comp.java.netbeans.modules.tasklist.devel |
|---|---|
| Message-ID | <[email protected]> |
Trond Norbye wrote:
> I have just started to look at the NetBeans sources, and hopefully
> contribute to the project....
>
> The first think I laid my eyes on was the SourceScanner-feature, in which
> I found some (in my eyes) unexpected behaviour.
>
> 1. It creates tasks for "tags" that do not reside in a comment block.
The tasklist is not java specific. Thus, you can add TODO markers
in your XML files, in your .txt files, in your .html files.
The list is generated by matching a regular expression (which
the user can customize, which defaults to
DefaultScanRegexp=\\bTODO\\b|\\bFIXME\\b|@todo\\b|\\bPENDING\\b|\\bXXX\\b
## Additional candidates: HACK, WORKAROUND, REMOVE, OLD
(See Global Options to customize it)
If we add in specialized behavior like "ignore matches outside
java comments" it complicates the user model I think.
I don't know how to write a regular expression for what you want
which would also work in the general case (e.g. when editing non-java
files), and would work for block comments etc.
> 2. It includes the complete line where it found the tag as a task, causing
> "normal" entries to look like:
> * @todo blah
> // @todo bla
> I would prefer to strip everything up to the the start tag.
>
> I have created a version that "fixes" these two things, but I encountered
> another "theoretical" problem during my tests...
>
> /* @todo blah */ int i = 0; /* @todo optimize this thing */
>
> The "old" version of the source scanner would then insert the whole line
> as a task, while my method would just get the first entry (since I cannot
> have multiple tasks on a single source line). (It is however not a big
> problem for me to concatinate the two strings, and get the following task:
>
> @todo blah @todo optimize this thing
>
> But who writes such code anyway....
Well, it's not as unusual as you think. The problem is that often the
tag does not appear at the beginning of the line. I myself write
code such as this:
hashMap = new HashMap(maxSize*2); // Decent factor? XXX
If you strip out the stuff on the left of the token you're left
with very little.
Here are some examples from the JDK source code which has
the same problem.
./javax/swing/text/rtf/RTFGenerator.java:953: for binary search. TODO. (Even though this is inefficient however,
./javax/swing/text/rtf/RTFGenerator.java:981: /* Not very efficient. TODO. */
./javax/swing/text/TabStop.java:116: (position == o.position) ); /* TODO: epsilon */
./javax/swing/BoxLayout.java:282: * Called by the AWT <!-- XXX CHECK! --> when the specified container
>
> And now the big question:
>
> Does anyone else agree with me?
Well, if you insist we could make it optional. But NetBeans already
has too many options. We're not quite emacs yet though :)
-- Tor