Community
Participate
Working Groups
Implement a Smart Text Search that allows participants to transform (or filter) base files before applying a text pattern. This is basically the idea from bug 268295 comment 7, but would also allow to solve bug 16426 and others. File search is often cumbersome when the text you want to find is not plain text in a file but somehow embedded in a structured format. Examples: - separate searches for Java .properties files that only match in keys or only in values - Java string literals and .properties files can contain ampersands that add mnemonics in the UI => search should skip the ampersands - search in Java string literals (also consider "+"-concatenated strings) - Javadoc or block comments can span multiple lines => search should skip the line breaks or at least the * at the start of lines - text embedded in HTML or XML files => search should strip away all markup tags and replace entities like "&" by their value To solve these and similar tasks, we could add a Smart Text Search where clients can contribute domain-specific transformers that normalize the base file contents and feed the extracted plain text to the existing (regex-capable) search engine. The UI should allow users to pick the transformers they want and add them in the order they want (e.g. search in .properties values and strip "&"). Think of this as a UI for a general map operator, Unix pipes with e.g. grep filters, Ant <filterchain>s, java.io.FilterReader, javax.xml.transform.Transformer, etc.
Just stumbled over this RFE because smart search would be really helpful for Java source search, e.g. ignoring comments, as was proposed in bug 16426. Since it's still not in Luna, can we please have it for the spring refresh?
(In reply to Gregor Rosenauer from comment #1) > Just stumbled over this RFE because smart search would be really helpful for > Java source search, e.g. ignoring comments, as was proposed in bug 16426. > > Since it's still not in Luna, can we please have it for the spring refresh? Do you plan to contribute it?
As much as I would like to see this feature come to life, I currently do not have the resources to contribute, I'm afraid, esp. since this is an RFE with a broad spectrum and needs work in various layers of the API as well as in JDT. However I really like the pipes and filters reference in the original proposal by Markus Keller, so if I can help in any way I'll do my best to contribute at least in specific parts.
(In reply to Gregor Rosenauer from comment #3) > As much as I would like to see this feature come to life, I currently do not > have the resources to contribute, I'm afraid, esp. since this is an RFE with > a broad spectrum and needs work in various layers of the API as well as in > JDT. > > However I really like the pipes and filters reference in the original > proposal by Markus Keller, so if I can help in any way I'll do my best to > contribute at least in specific parts. Markus, (In reply to Gregor Rosenauer from comment #3) > As much as I would like to see this feature come to life, I currently do not > have the resources to contribute, I'm afraid, esp. since this is an RFE with > a broad spectrum and needs work in various layers of the API as well as in > JDT. > > However I really like the pipes and filters reference in the original > proposal by Markus Keller, so if I can help in any way I'll do my best to > contribute at least in specific parts. The ground/initial work has to be started by someone, and I don't think Markus has time. Markus?
