Ability to disable Java intention when editing an incompatible language

This is still a problem for us when editing Gosu code...the Java intention is offered and it inputs syntactically incorrect stuff.

I found this old post:

https://intellij-support.jetbrains.com/hc/en-us/community/posts/206126779-Is-it-possible-to-disable-java-intention-actions-for-another-language-

so it looks like there were some thoughts about how to improve the situation, but I can't find any documentation or examples that would suggest it was actually completed.

It seems to me that, broadly, solutions would fall into three categories:

  • A way to un-register the old intention, and replace it with one that delegates to the right language
  • An extension to the description so that "language" is part of how an intention is registered
  • A level of indirection or delegation, so that intentions find and use language-specific "invoke" implementations

Are any of these now possible? And if not, could someone outline what JetBrains would consider acceptable solutions, so I can estimate how much work it might be to contribute this enhancement?

 

 

4 comments

Hi Richard,

IDEA was developed as java-based IDE. So in all the code it is expected that Psi"Member" is a java class member. In some cases where it was reported, the language was checked or some other conditions were added. It's impossible from our side to add blindly checks as this could break support e.g. for groovy or scala. I don't see how you want to un-register the intentions, do you have your own IDE or is it a plugin so java code could appear in the IDE as well? Both other suggestions require a lot of work from our side as well, can you name the problems you have explicitly? If there are a lot of them, why do you inherit from java PSI if the language is very different? (I know that the question is hard after a lot of work is already done, sorry)

Anna

0

Thanks, Anna. I think maybe I'm just not understanding how to accomplish the goal.

Let's use an example the "Introduce Local Variable" inspection, because that's the one that was reported to me as a bug.

If you type the expression "String".getBytes() into a Java method body, it offers you the Introduce Local Variable intention. Invoking it will cause "byte[] bytes = "String".getBytes();" to be inserted.

If you type the same expression into a Groovy method body, it also offers you the Introduce Local Variable intention. Invoking it here will cause "def bytes = "String".getBytes()" to be inserted.

If you type the expression into a method body in our plugin (the Gosu language) it invokes the Java version of the plugin, which means that it incorrectly inserts "byte[] bytes = "String".getBytes();" when what is needed is "var bytes = "String".getBytes()"

Inside my language plugin, how do I get it to use my implementation of this intention instead of the one that was created for Java?

0

These are different intentions. Java intention doesn't work inside groovy because GrExpressions do not inherit PsiExpression. Do you inherit from PsiExpression? If yes, why? What do you want to achieve with this?

Anna

0

I see what you're saying -- rather than extending only from the core Psi interfaces, some things are extended from the Java Psi classes.

The old message I found was from 2011, so they probably committed to this approach a while ago, when the whole internal organization of the JetBrains code was very different.  (I'm looking at the 141 branch, and I don't find separate psi classes for Groovy at all.) But I'm not certain.

In any case, thank you for explaining the difference in behavior.

0

Please sign in to leave a comment.