XmlCompletionContributor is stopping the completion result set before my plugin's completion provider/contributors
This appears to be a very recent change, perhaps in 2017.1.2. My plugin registers a completion contributor for language="any" and order="first". This has allowed my plugin to add completions inside of SCRIPT tags in HTML files (well, a MultiplePsiFilesPerDocumentFileViewProvider-based file type). Now my plugin's completion contributor isn't being invoked in some cases, and I've tracked it down to XmlCompletionContributor:333:
if (descriptorFile != null && containingFile != null) {
final boolean acceptSystemEntities = containingFile.getFileType() == StdFileTypes.XML;
final PsiElementProcessor processor = new PsiElementProcessor() {
@Override
public boolean execute(@NotNull final PsiElement element) {
if (element instanceof XmlEntityDecl) {
final XmlEntityDecl xmlEntityDecl = (XmlEntityDecl)element;
if (xmlEntityDecl.isInternalReference() || acceptSystemEntities) {
final LookupElementBuilder _item = buildEntityLookupItem(xmlEntityDecl);
if (_item != null) {
resultSet.addElement(_item);
resultSet.stopHere();
}
}
}
return true;
}
};
Even though I try to register my completion contributor as order="first", it appears that it's getting bumped down the priority list because in CompletionService.getVariantsFromContributors(), the contributors list looks like:
- ComboEditorCompletionContributor
- CompletionContributorForInplaceRename
- LiveTemplateCompletionContributor
- DomCompletionContributor
- XmlCompletionContributor
- MyPluginsCompletionContributor
As you can see, XmlCompletionContributor is just before mine, and it's stopping collection of completions.
Any idea why this change was made? Any suggestions on what I can do to ensure that my contributor is invoked reliably?
Thanks much in advance!
请先登录再写评论。
UPDATE: I've installed Community Edition 2016.3 and 2017.1 and have verified that 2016.3 works properly with my completion contributor being engaged consistently. 2017.1 is better than 2017.2 but does exhibit the issue. What I mean by that is that the same problem happens with another of my completion contributors which should be engaged after the live template completion contributor, and in 2016.3 and 2017.1 it is, but in 2017.2 it's not. This is important because that completion contributor does call stopHere() to keep other completion contributors from running that add noise to completions in my plugin's main language.
So it does seem that something changed with completion contributor order in 2017.* with the change being more extreme in 2017.2 than in 2017.1.
Thoughts?
For the folks at JetBrains, any thoughts on this? I've tried to force my completion contributor to be before XmlCompletionContributor, but when I do that it says that requested sort order can't be honored because XmlCompletionContributor wants to come first so anything requesting to come before that is infeasible.
One other aspect of this that's probably relevant...as I mentioned this is happening inside of a MultiplePsiFilesPerDocumentFileViewProvider document, and I noticed that the problem occurs in between my "injected" portions of the doc, e.g.:
So for whatever reason the logic in XmlCompletionContributor.addEntityRefCompletions() has been changed in 2017.* to be "confused" in this type of situation such that it short-circuits completions before other contributors can be engaged.
Should I log a bug against the plugin SDK for this?
Thanks!
Sorry, that was my change and it was a part of refactoring to replace deprecated CompletionData with proper contributors for XML. Completion is stopped only after & to prevent irrelevant results from WordCompletionContributor cluttering entities completion. You can use order="first, before xml" for your contributor to circumvent this
Thanks, Dennis! I wasn't aware of the compound ordering syntax. I'll give that a shot and see if it does the job. Either way I'll post back here to confirm the resulting behavior.
Dennis, that did the job! Thanks so much for the info.