Community
Participate
Working Groups
I think that there are some down sides to having the Java -> Editor -> Content Assist -> Advanced page name: * The name does not describe the page, and the settings on that page are not inherently more advanced than some of the settings on the Content Assist page. * If others follow this convention filtering the tree will result in a whole lot of unrelated pages showing up when people type "Advanced". * The fact that it's a sub-page already indicates that it is about finer grained and more advanced settings. And there may be future "Advanced" settings since this page is pretty much filled, and those will want their own pages. I suggest calling it "Proposals" since that's what on it. If it really is important to distinguished 'advanced' from non-advanced pages we should do it with some kind of UI tag that other pages can use, and that way we could filter the whole prefs tree to hide all advanced settings. (I considered submitting a new report for that but I'm not yet sure if it's a good idea.)
What can be configured are the proposal processors (or kinds), not the proposals. In addition the time to fetch parameter names from proposals can be set on that page. I agree that 'Advanced' is not the best name but so far we don't have a better one. Feel free to propose other names.
You could consider reorganizing the two pages and calling that one "Activation", and giving it "Triggers" and "Proposal Kinds" sections.
We already have Auto-Activation on the main page.
I know, I was suggesting moving that from the main page since from the user's point of view all but the Javadoc thing on the Advanced page is about what happens on activation. This would require making the layout a bit more concise.
All that's beyond changing the label is beyond 3.2.
Get rid of deprecated state.
.
