Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.6.0.Release
-
Fix Version/s: None
-
Component/s: DSL Support
-
Labels:None
-
Number of attachments :
Description
It would be nice to be able to turn of underlines altogether in specific places.
I can think of two interesting use cases for Gradle support:
1) It may be useful to turn of underlining altogether in all .gradle files.
The reason for this could be that the DSLD will not be complete and won't necessarily understand
all the plugins that get dynamically loaded. So many things will be underlined. Turning this off
may be useful... we will not get the annoying underlines, but still get some content assist and
Java doc hovers for those things that do work.
2) It may be useful to turn of underlining in very specific sections of the AST.
For example:
task foo {
...
}
task bar(....) {
}
The foo 'variable reference' and the bar 'method reference' in the above example shouldn't be underlined. This is where the tasks foo and bar are being defined.
Not sure if we should use the same mechanism for both use cases...
Currently, the easiest way to do this is to extend the typeLookup extension point. Subclass AbstractSimplifiedTypeLookup and in the lookupTypeAndDeclaration method, do this:
boolean shouldDisable; // set this flag in the initialize method public TypeAndDeclaration lookupTypeAndDeclaration(ClassNode declaringType, String name, VariableScope scope) { if (shouldDisable) { return new TypeAndDeclaration( declaringType != null ? declaringType : groovyClass, VariableScope.OBJECT_CLASS_NODE); } else { return null; } }This implementation oversimplifies things. It will set the infer everything as Object, regardless of where and in what file, so this in itself isn't what you want. However, in the initialize method, you can make some quick checks and see if you want to turn the functionality on or off (eg- you can look at the file extension of the compilation unit and set a flag).