Also, I wanted to clarify the second issue. The problem is that all variables are being interpreted as AT_END, so even if you return VariableInfo with AT_BEGIN or AT_NESTED, IntelliJ won't recognize the variable for auto-completion until after the end of the tag. Thus, something like a for loop wouldn't work. e.g.:

<%-- assuming loopVar had returned VariableInfo with AT_NESTED specified --%>
<g:forEach var="loopVar" className="foo.Foo">
<%-- loopVar should be in scope for auto-completion in IntelliJ right here with type foo.Foo --%>
</g:forEach>

<%-- in IntelliJ 5.0.2, the loopVar only was accessible for auto-completion at this point, which is clearly invalid since the variable is actually only available within the body of the g:forEach tag --%>

Does that clarify the issue? If it is fixed in 5.1, then that would be wonderful. There's no way for me to tell on build 4155 since it has the general auto-completion bug, but I can confirm that it is fixed if I can get my hands on 4157.

Thanks for your help,

Brian

It would be GREAT if you could address this issue in the upcoming 5.1.1 release.

Please let me know if you'd like me to create separate bug issues for these types of problems. I figured that since it is pretty closely related to this issue that I could piggy-back.

e.g.
class FooBean<T extends Foo> {
public T getFoo() { return foo; }
}

class Foo {
public getX() { return x; }
}

class Bar extends Foo {
public getY() { return y; }
}

class BarBean extends FooBean<Bar> {
}

Then, in JSP, do something like:

${barBean.foo.y}

where "barBean" is an instance of BarBean. Note that in this case, IntelliJ would detect that the "T" parameter in FooBean is of type Bar, and thus allows auto-completion of the "y" property of Bar.

Does that make sense? Let me know if you'd like a more explicit example (with sample project/code).