This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If a tag has a namespace, then the ending tag isn't highlighted correctly if the cursor is placed in the start tag. For example: <g:if> ... </g:if> if the curser is placed in the "<g:if>", the "</g:if>" isn't properly highlighted (and in fact shows as an unclosed tag). Additionally, completion doesn't work (but I guess that's a separate bug).
Still valid --> Changing TM to 7.2
AbstractHighlightsContainer from spi.editor.highlighting.support might help with this (there are some implementations registered in groovy.gsp layer.xml but they might not be intended for this purpose - e.g. EmbeddedSectionsHighlighting is used only for highlighting embedded groovy code) We should check already used implementations and either fix one of the current ones or implement new one so we can finally have this behavior for GSPs.
Hi Athompson (CCing also Alex, so Hi Alex :)), could one of you guys help me with something? I'm trying to improve (rewrite) our GSP lexer to be able to fix some issues from that area, but unfortunately I don't have strong knowledge of GSP grammar and thus I'm not completely sure if some syntactic rules are possible in GSP or not. So few syntactic questions:) 1] Does GSP allow construct like "@{ ... }" ?? 2] Does GSP allow construct like "!{ ... }!" ?? 3] Does GSP allow construct like "%{ ... }%" ?? (I'm aware of gsp style comments "%{-- ... --}%" but is it possible to use it somewhere else?) 4] Does GSP allow construct like "<%! ... %>" ??
I don't think that any of the examples are a 'gsp' syntax that should do something special. The only thing that resembles #4 is JSP style comments, e.g. <%-- ... --%>
Thanks a lot for a quick response Alex! I'm glad to hear that. Our current lexer is processing these constructs, but I wasn't able to find any reference that would show these are valid GSPs. Great that you confirm it. Thank you one more time!
Ok, referring my comment 2 this was never properly implemented. BracesMatchers and BracesMatcherFactory has to be implemented for GSPs (JspBracesMatching might be an inspiration). I already have a new GSP lexer, so it shouldn't be complicated. Anyway targeting to the TM = Next as we are way after the feature freeze and this will be whole new functionality.
*** Bug 166632 has been marked as a duplicate of this bug. ***
*** Bug 167891 has been marked as a duplicate of this bug. ***
Fixed in: http://hg.netbeans.org/web-main/rev/d7a619844f78 It's only a part of the development sources, so please anyone interested in the change, use daily builds instead of newly incoming NB73.
Integrated into 'main-golden', will be available in build *201301150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d7a619844f78 User: Martin Janicek <mjanicek@netbeans.org> Log: Rewriting GSP lexer, indenter and the braces matcher as a fix for issues #153424, #168004, #202248, #202249 and #209989