Is it possible to disable java intention actions for another language?

Hello,

There are many different intention actions and many of them are related only to Java (e.g. CreateFieldFromParameterAction). Is it possible to disable these intentions for custom language? Implementation of isAvailable method in CreateFieldFromParameterAction class doesn't check the language of PsiParameter i.e. can return true for any language:

public boolean isAvailable(@NotNull Project project, Editor editor, PsiFile file) {
    PsiParameter myParameter = findParameterAtCursor(file, editor);
    if (myParameter == null) return false;
    myName = myParameter.getName();
    final PsiType[] types = getTypes(myParameter);
    PsiClass targetClass = PsiTreeUtil.getParentOfType(myParameter, PsiClass.class);
    return
      myParameter.isValid()
      && myParameter.getDeclarationScope() instanceof PsiMethod
      && ((PsiMethod)myParameter.getDeclarationScope()).getBody() != null
      && myParameter.getManager().isInProject(myParameter)
      && types != null
      && types[0].isValid()
      && !isParameterAssignedToField(myParameter)
      && targetClass != null
      && !targetClass.isInterface()
      ;
  }




Thanks,
Dmitriy
4 comments
Comment actions Permalink

Hello Dmitriy,

No, it's not possible. You've seen the source code; you see that it doesn't
query any extension points or anything like that.

There are many different intention actions and many of them are
related only to Java (e.g. CreateFieldFromParameterAction). Is it
possible to disable these intentions for custom language?
Implementation of isAvailable method in
CreateFieldFromParameterAction class doesn't check the language of
PsiParameter i.e. can return true for any language:

public boolean isAvailable(@NotNull Project project, Editor editor,
PsiFile file) {
PsiParameter myParameter = findParameterAtCursor(file, editor);
if (myParameter == null) return false;
myName = myParameter.getName();
final PsiType[] types = getTypes(myParameter);
PsiClass targetClass = PsiTreeUtil.getParentOfType(myParameter,
PsiClass.class);
return
myParameter.isValid()
&& myParameter.getDeclarationScope() instanceof PsiMethod
&& ((PsiMethod)myParameter.getDeclarationScope()).getBody() !=
null
&& myParameter.getManager().isInProject(myParameter)
&& types != null
&& types[0].isValid()
&& !isParameterAssignedToField(myParameter)
&& targetClass != null
&& !targetClass.isInterface()
;
}


--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Dmitry,

We have this problem with the Gosu plugin, IDEA displays the bult-in intentions in many places and as Dmitry said, we have no way of turning them off. It would be better if intentions were registered on a per-language basis. Alternatively, we could use a filter to disable the intentions we don't want. This method would have a lower impact on the existing IDEA code. So, my question is this: If we modified the IDEA code to add an extension point for an intetion filter, will you be wiling to accept a patch and include it in the next version of IDEA?

Thanks,
Dumitru.

0
Comment actions Permalink

I had this problem at one point due to my trying to reuse too many of the Psi classes. I think PsiMethod was one of the ones that caused some trouble. I would just create new types that won't get captured by the visitors in the Java instpections. I doubt you need all the functionality in the Psi classes in Gosu.

0
Comment actions Permalink

Hello Dumitru,

Actually we've been planning to implement per-language registration of intentions
(with the ability to specify the language directly in the intentionAction
XML tag) for a long time already; unfortunately we never got around to implementing
this in time for IDEA 11 release. If you can implement this, we'll be happy
to consider the patch for inclusion. We don't think that adding a separate
extension point for filtering is the optimal approach.

We have this problem with the Gosu plugin, IDEA displays the bult-in
intentions in many places and as Dmitry said, we have no way of
turning them off. It would be better if intentions were registered on
a per-language basis. Alternatively, we could use a filter to disable
the intentions we don't want. This method would have a lower impact on
the existing IDEA code. So, my question is this: If we modified the
IDEA code to add an extension point for an intetion filter, will you
be wiling to accept a patch and include it in the next version of
IDEA?

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Please sign in to leave a comment.