Community
Participate
Working Groups
We have a java completion proposal computer, but it should only be used for projects of a specific type. However, there is no way to eliminate our computer for projects that don't match this criteria. If there were an enablement (optional) element on the extension point, we'd be able to prevent this completion proposal category from showing up on project where it makes no sense. example: <extension point="org.eclipse.jdt.ui.javaCompletionProposalComputer" id="jaxbCompletionProposals" name="%jaxbCompletionProposals"> <proposalCategory icon="icons/full/etool16/jaxb_facet.gif"/> <enablement> <with variable="project"> <test property="org.eclipse.wst.common.project.facet.core.projectFacet" value="jpt.jaxb" forcePluginActivation="true"/> </with> </enablement> </extension>
> If there were an enablement (optional) element on the extension point, we'd > be able to prevent > this completion proposal category from showing up Showing up where exactly?
Showing up as a category when hitting ctrl-space. If it makes no sense to have jaxb proposals in a particular context, then the category itself should not show up. i.e. "Press ctrl-space to see JAXB proposals"
So, an option to hide categories with 0 proposals would also do the trick for you?
Effectively, sure. Do you mean a user option or an extension option?
> Do you mean a user option or an extension option? A user option. I think the user should decide whether he wants this or not. Imagine he knows the third category is 'Templates' and hits 'Space' two times to get there. If that becomes unreliable because the second category decides to be skipped if empty, then his workflow is doomed.
Then no, this is not what I'm talking about at all. Our completion proposals will only show up on certain projects. On other projects they will *always* be empty, and the user will *always* get an empty category. In fact for *most* projects, our empty proposals will show up. And we actually have two of them (two different kinds of projects). The simple fact that a user has to remember that he needs the fourth or fifth category itself is probably bad form.
OK I see. I would accept a high quality patch that implements the solution described in comment 0.
If you have any requests for enablement variables, please let me know. I'll take a look at this after Indigo release.
(In reply to comment #8) > If you have any requests for enablement variables, please let me know. Nothing at the moment and I can't recall any requests in this area. > I'll take a look at this after Indigo release. Thanks!
Created attachment 197893 [details] proposed patch Patch handles enablement for the following two scenarios: - specific content assist category menu items - invoking content assist within source code Tested against our extensions (and existing java extensions): <extension point="org.eclipse.jdt.ui.javaCompletionProposalComputer" id="jaxbCompletionProposals" name="%jaxbCompletionProposals"> <proposalCategory icon="icons/full/etool16/jaxb_facet.gif"> <enablement> <with variable="project"> <adapt type="org.eclipse.core.resources.IProject"> <test property="org.eclipse.wst.common.project.facet.core.projectFacet" value="jpt.jaxb"/> </adapt> </with> </enablement> </proposalCategory> </extension> Comments are appreciated. I was potentially overly defensive, not being that familiar with the code. I was unsure how to handle ContentAssistProcessor, as it is a concrete internal class, but seems to never be instantiated, and I couldn't test implementations of that specifically. I ended up treating it as though it were an abstract class. API (extension point schema) was also updated.
Paul, I will look at this probably in September. We are currently 100% busy with Java 7.
No worries, just wanted to give plenty of time for feedback back and forth.
Hi Paul, I finally reviewed your patch. Looks good in general. Some minor changes need to be made: - the example in the extension point definition should be adjusted - please adjust copyright date in the extension point definition - new additional checks should only be made if all other checks return 'true' - CompletionProposalCategory.matches(IJavaProject) should only compute the expression once and cache it - the signature change of #computeEnablement(ITextEditor) is not needed - use EditorUtility.getJavaProject(editor.getEditorInput()) to get the project - I would probably also add the check to SpecificContentAssistExecutor.invokeContentAssist(ITextEditor, String) since someone might directly use it in the future (instead of going via SpecificContentAssistAction). - all new methods need Javadoc and a @since 3.8 - add your credentials to the Java files, e.g.: Dani Megert <dani@eclipse.org> - this is a bug - https://bugs.eclipse.org... - please add test cases or add an example plug-in to verify that it works
(In reply to comment #13) > Hi Paul, > > I finally reviewed your patch. Looks good in general. Some minor changes need > to be made: > - the example in the extension point definition should be adjusted How? The enablement tag is optional and the existing example (which seems to be a real example) doesn't make use of it. What would you suggest? > - please adjust copyright date in the extension point definition done > - new additional checks should only be made if all other checks return 'true' done > - CompletionProposalCategory.matches(IJavaProject) should only compute the > expression once and cache it done > - the signature change of #computeEnablement(ITextEditor) is not needed > - use EditorUtility.getJavaProject(editor.getEditorInput()) to get the project done. helpful utility, that. > - I would probably also add the check to > SpecificContentAssistExecutor.invokeContentAssist(ITextEditor, String) since > someone might directly use it in the future (instead of going via > SpecificContentAssistAction). would I just check enablement for that category and if not enabled, then *not* set it to be included? > - all new methods need Javadoc and a @since 3.8 done > - add your credentials to the Java files, e.g.: > Dani Megert <dani@eclipse.org> - this is a bug - https://bugs.eclipse.org... done > - please add test cases or add an example plug-in to verify that it works working on example plug-in ... Can you provide answers to the two above questions? Everything else is taken care of or in progress. Thanks.
Created attachment 208826 [details] test plugin Test plugin. If the project is named "Enabled" content assist category is enabled (for text regions). If the project is named otherwise, content assist category is not enabled.
Created attachment 208827 [details] updated patch Made all above changes except: - Updated example. The current example doesn't make use of enablement, enablement is optional, and enablement is fairly well understood (or at least documented all over the place). I didn't think it was appropriate to add enablement to the current example. - Specific content assist. I feel that if a user is *specifically* invoking content assist for a given category, that the content assist - even if there are no proposals due to not being enabled - should proceed normally. There just won't be any proposals returned. The whole point of enablement is to filter categories from the default invocation, not for any need to specifically prevent a category from being invoked.
> - Updated example. The current example doesn't make use of enablement, > enablement is optional, and enablement is fairly well understood (or at least > documented all over the place). I didn't think it was appropriate to add > enablement to the current example. Fair enough. > - Specific content assist. I feel that if a user is *specifically* invoking > content assist for a given category, that the content assist - even if there > are no proposals due to not being enabled - should proceed normally. There > just won't be any proposals returned. It's a bit more tricky: a contributor might enable the category e.g. only for projects of a certain type/nature and then write code that relies on this, e.g. by doing a cast inside the proposal computer.
Created attachment 208966 [details] updated patch OK, I updated the specific content assist to disable if the enablement test fails.
Thanks for the updated patch Paul. I've slightly modified your credential string and updated the copyright date to 2012. Fixed in master: 9538bb8c56138fb59335cd939a339e0cc7354a87
Thanks. What do I need to do to get this taken up by the 4.x stream?
(In reply to comment #20) > Thanks. > > What do I need to do to get this taken up by the 4.x stream? Nothing. 4.x automatically consumes JDT from the 3.x builds.
