Community
Participate
Working Groups
Please add support for TODO and such tags in plugin.xml and other PDE artifacts
I will try to do something for M5, most likely only in MANIFEST.MF and plugin.xml files first. Anything else you want Eugene as a spoiled plug-in developer ;)?
Thanks Chris, it is not like I want it, but I think support those tags in plugin.xml would be quite useful. Then I think in order of interest feature.xml, site.xml and manifest.mf, though those 3 mostly generated, so personally I'd be happy with just plugin.xml
no need for PDE to reinvent the wheel here... we should wait until the Platform provides something
Chris, if I am not mistaken, JDT is using its own builder to fetch TODOs and other tags. I think WTP is using similar approach as well as tools like DLTK. So it is unclear how it can be supported for arbitrary text files and it doesn't look optimistic given that bug 26849 been opened in November 2002. Unless Platform/Text is actually committed to support this feature, I wonder if you can reconsider.
If we have time, we'll try to look at it for M5, but this seems a lot more involved than it should be and we will be mainly focusing on getting the API tools ready for public consumption in M5. We're always looking for contributions so I'll mark this a bugday. We can't guarantee anything but since it's important to you, we'll consider it ;)
(In reply to comment #4) As the implementor in WTP, my interest was purely about the definition of the task tags themselves, the strings and priorities, and less about the method for their discovery. Our languages don't typically produce output files, so we opted to avoid a builder. Having a common list of task strings and priorities could at least simplify the user experience for implementors who do use a builder--they wouldn't need much additional UI.
(In reply to comment #6) > (In reply to comment #4) > As the implementor in WTP, my interest was purely about the definition of the > task tags themselves, the strings and priorities, and less about the method for > their discovery. Our languages don't typically produce output files, so we > opted to avoid a builder. Nitin, that is very interesting. Can you please outline how WTP is collection these tasks? Are you using some proprietary background job similar to builder's job? I do agree that common configuration API and UI for these tags would be really great, though bug 26849 doesn't really imply that.
(In reply to comment #7) > Nitin, that is very interesting. Can you please outline how WTP is collection > these tasks? Are you using some proprietary background job similar to builder's > job? Pretty much, yes, then delegating to declared extensions for files of the supported content types. > I do agree that common configuration API and UI for these tags would be really > great, though bug 26849 doesn't really imply that. If not, it should. I'm not sure that unification of the actual scanning would ever be practical, unless there was an extension point provided specifically to update task tags, similar to Save Actions, but generalized. And then there's still the non-incremental cases to consider.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
WTP handles these file types generally, as they're XML files.
