Hm, it seems I removed this on Jan 20th 2009 for ADS 7.5 (note to self: internal ADS hg-repo, changeset #5d664ed9ede0).

Not sure why, but apparently the old syntax-based braces matching didn't work back then so I've added a simple text-based braces matching.

I've just tested it now and it seems that the syntax-based braces matching works again, so I guess we can revert.

Replace in BaseSQLMimeRegistration the anonymous BracesMatcherFactory with a

new org.netbeans.modules.editor.bracesmatching.LegacyEssMatcher()

Close the issue if it works.

Doesnt seem to work in 12.0.0-rc-22-7 and Build #: 29609

This is a change that has to be done in ADS. I've re-assigned to Niels.

In RC-22-9 I've added :

    @Override
    public Iterable<?> getCustomMimeLookupObjects() {
        return Arrays.asList(new SQLCompletionProvider(), new RefresheableFontColorSettingsImpl(), new org.netbeans.modules.editor.bracesmatching.LegacyEssMatcher());
    }

But not sure if that fixed it.  The uncommented brackets match each other ok, but the commented brackets also match the outer brackets incorrectly.  Not a big deal.

This issue represent two bugs :

1. uncommented matching brackets take into consideration commented brackets. (Fixed in v7)
2. commented brackets should not match at all.  (See broken in v12)

The new vincaed fixes #1, but not #2.

#2 is how it worked in ADS 7 too.

From the way the code looks, if the caret is on a bracket, it first tries to respect getBracketSkipTokens and ignores comment/quoted tokens while searching for a match.

But if the caret itself is on an ignored token it just matches doing a text search, regardless of tokens.

I could patch the existing code to return no matches whatsoever if the caret is inside a comment or quoted string (aka one of the getBracketSkipTokens).

Actually, I think this behavior is acceptable.

Verified in 12.0.0-rc-23-1