Community
Participate
Working Groups
In Content Assist > Advanced preferences, we should disable the proposals kinds which are already covered by an enabled and checked proposal kind. For example, if 'Java Proposals' is enabled and checked, disable 'Java Non-Type Proposals' and 'Java Type Proposals'. See bug 464850 for background.
Maybe bug 464850 works as designed, but the design is bad. It's confusing to: - silently disable proposal kinds that are already included in other kinds - only do that on restart and not directly on Apply / OK => after enabling all proposal kinds, you get duplicate proposals until restart I would not try to explain the current hack in the UI or add even more hacks to special-case some "Java *" proposals, but rather fix the implementation so that the hack and the explanations become unnecessary. Fiddling with user preferences behind the scene is ugly, and offering an API to do that is even worse. PreferenceConstants#get/setExcludedCompletionProposalCategories(..) should be deprecated. The general problem is that some proposal kinds replace the functionality of another kind. In JDT, the "Java Proposals" kind includes the two other "Java *" kinds. Mylyn (who asked for bug 140886) has proposal kinds that replace the "Java *" kinds. The element "javaCompletionProposalComputer" of the extension point "org.eclipse.jdt.ui.javaCompletionProposalComputer" should get a new child element "overrides" whose values are ids that point to other javaCompletionProposalComputer ids. Then, proposal computers that are overridden in other active computers can silently be skipped when computers are loaded. This strategy also nicely solves all the bugs that arise when a proposal computer that overrides others gets uninstalled. In that case, the previously skipped computers automatically become active again, and no hacks like bug 222403 and bug 250629 are necessary. The UI could tell about the override mechanism, but that's no critical.
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. -- The automated Eclipse Genie.
