Bracket matching in a temporary [not visible] editor

Hi Mike,

Did you set "BracketHighlightingVisible" to true on the temporary editor you were using?  If that is false, I don't believe the bracket token properties get updated.

I thought I had set "BracketHighlightingVisible" but I guess it was possible I accidentally set "BracketHighlightingInclusive" instead.

However I realized that this last phase of formatting will only apply a few changes, and there will be no long lines of text at this point, so I can do the indentation in the main window without creating a temporary editor. 

The original performance issue was caused by the fact that we had very long lines of text in the earlier phases.

I did find that if I suspend events then the Selection.MoveToMatchingBracket() does not move at all. (So I think an Editor without a UI may act similarly) To avoid a lot of flickering from the select/indent steps I suspended painting instead of suspending events and that works OK. 

I tried it again and I guess I must have set "BracketHighlightingInclusive" rather than "BracketHighlightingVisible" since it is now working.

The bad news is that it does not work any faster than when I use the 'visible' editor - in fact it is very slightly slower. (Maybe because of the time required to create/initialize the temporary editor and load a dynamic language file into its' Document.)

The good news is that by using the temporary editor there is no flickering, and if the user then uses 'Undo' the original text is restored immediately. (When using the real editor it could take up to 30 seconds to undo)

I again tried to use SelectedView.BracketHighlighting but both BracketToken and MatchingBracketToken remain null.
(So I assume the BracketHighlighting property is not supported for Dynamic languages.)

Is there an alternative to Selection.MoveToMatchingBracket() if all I need to know is the offset of the matching bracket?

The information must be available somewhere since MoveToMatchingBracket() must use it. But is it exposed through the public interface?

Thanks
Mike

Hi Mike,

The "SyntaxEditor / General Features / Text Visualization Features / Bracket Highlighting" topic in the documentation that comes with the product talks about how to add support for custom syntax languages.  Both dynamic and non-dynamic languages support it, but in slightly different ways.

The MoveToMatchingBracket code has some complex logic in it that tries to determine if a token next to the caret is a bracket and then uses the view's BracketHighlighting object's public properties to access the match.  If that info isn't available, it will fall back to getting a TextStream and will use the GoToPreviousMatchingToken method to find a match.

Thanks. I think what I had missed is the overloaded version of TextStream.GoToNextMatchingToken() that takes both the 'open bracket' token and the tokenId of the matching 'end bracket' token.

I had previously tried to position the TextStream at the '(' and use GoToNextMatchingToken(ts.Token) to go to the matching ')' but that did not seem to work. When I added the TokenId of the ')' then it works. Since there is only one matching EndBracket TokenId (unless special customization has been added) I did not think it was required to specify the TokenId of the end bracket token. 

This should allow me to use only the TextStream in a temporary Document so that i can perform the updates in a StringBuilder, as I did for the first phase of the process. That should be a lot faster that creating an editor and using Selection.Indent().