Community
Participate
Working Groups
In order to contribute a content assist category and have it disabled by default, one needs to add it to PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES (disable it in the default list), and to PreferenceConstants.CODEASSIST_CATEGORY_ORDER with a cycleState > 65535 to ensure it's disabled even for content assist cycling. However, if a new proposal category is introduced matching the above criteria, and a user has previously made any changes to the default/cycling list, then the proposal category will be enabled by default, because the user's exclusion list (not containing the new proposal category) would override the default one. This also makes it difficult to contribute new completion categories as it effectively requires that they be near perfect on inclusion due to the highly visible nature of code completion.
It's mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=547833#c10 that appending the new proposal category to the user's exclusion list on the first startup of the Eclipse release that introduces it isn't ideal. The only other way I see of doing this is to explicitly record whether the user has enabled/disabled a proposal category (rather than just disabled). This way if it isn't present, it's a new option and its default should be respected.
(In reply to Roland Grunberg from comment #1) > It's mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=547833#c10 > that appending the new proposal category to the user's exclusion list on the > first startup of the Eclipse release that introduces it isn't ideal. > > The only other way I see of doing this is to explicitly record whether the > user has enabled/disabled a proposal category (rather than just disabled). > This way if it isn't present, it's a new option and its default should be > respected. ^^ This is the sane way of doing it IMHO.
Roland, can you please check if the strategy used in bug 511443 can be useful here?
Yes, I believe the logic in Bug 511443 will work, but it will need to be made a bit more generic so that we're not adding too much code every time we have a new code assist to exclude by default : initializeCodeassistCategoryDisabled(String id) - This would get called somewhere in the bundle's Activator#start(). It checks if the user has their own preferences (that override the default set) AND if the the migration for the code assist has not been run, add the code assist to the user's exclusion list, and set the "content_assist_${id}_migrated" property to true. Each new content assist needing to be disabled will have its own property that persists. isCodeassistMigrated(String id) - checks the boolean value for "content_assist_${id}_migrated" setCodeassistFavoriteStaticMembersMigrated(boolean migrated) - sets the value of "content_assist_${id}_migrated" After introducing these, every new code assist being introduced would only need an additional method call somewhere in the Activator#start() (in addition to the regular additions to PreferenceConstants for content assist)
Moving to 4.15.
New Gerrit change created: https://git.eclipse.org/r/156535
Gerrit change https://git.eclipse.org/r/156535 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=8396db0845ebcaab6b5dd36de93803822165a73f
Verified for 4.15 RC1 using I20200226-0600 build
