Cursor Position for Bracket Match of keywords

Hi Mike,

Thanks for evaluating SyntaxEditor.  Let me answer your questions.

There isn't a way to differentiate the patterns for various language dialects in the dynamic languages.  But what you could do is define a separate pattern group for each and then in a code-behind class for the language after it loads, remove the appropriate pattern groups from the parent state that aren't valid for the dialect you're using.

As for the bracket highlighting, that feature was originally designed to just support single character brackets.  But I believe in the documentation for the Bracket Highlighting feature, the last section talks about an event you can handle where you could probably get more advanced bracket highlighting working since it lets you pick which tokens to use for the pair.  You can also have it not highlight either if there is no match in that case.  You could implement those things even with the dynamic language.

We're getting close to designing how bracket highlighting will work in our newer WPF/Silverlight SyntaxEditor object models and have included your comments in the design specs for that so that we can hopefully come up with a more flexible model there.  We eventually hope to port that object model back to WinForms once it has all the same feature areas covered.

I was not expecting to be able to create a single XML file to define multiple dialects. I would define a separate file for each dialect and load the appropriate one when the user connects to a new data source.
The dialects differ far too much to be handled any other way.

I will need to look into the code behind option for bracket matching.
(and for a few other things I think)

I am also hitting problems with regular expressions - some of which dont seem to work correctly.
For example
   "^\s*\.?EXIT"
should match the token 'EXIT' or '.EXIT' when it is the first non-whitespace token on a line.

In your editor it correctly matches either token if that token starts in the first column of a line but not if there is any whitespace before the token.
I tried substituting your {whitespacemacro} for \s but that didn't work either.

I had similar problems matching complex numeric formats, although in that case I was eventually able to find a string that worked. I guess I need to read your docs on the regular expressions that you support. (I was expecting to be able to simply paste my existing patterns into your file but it looks like you are either using a different regular expression engine or maybe you 'pre-process' the patterns before handing them to the regular expression engine.) 

thanks

Hi Mike,

I tried that same regex in the find/replace dialog in our SDI Editor sample and it found EXIT fine, even when it was indented.

I never thought of trying it in Find/Replace - I just used it in the dynamic language file.

Knowing that it worked in Find I took another look at the language file and realized that the pattern group that contains these patterns (with optional whitespace at the front) were defined as the 3rd group - after Whitespace and LineTerminator.

When I moved it to first place it started working as expected.
I need to define all pattern groups that contain whitespace at the start of the pattern BEFORE I define the pattern for Whitespace.
I wrote the language definitions for my current tool many years ago and had forgotten that.
When I created the test language for your tool I based it on your example files - all of which seem to define Whitespace and LineTerminator first.

Thanks

I found that you have already implemented a fix for one of the problems I was having with Bracket Highlighting.

If I set the property
    BracketHighlightingInclusive = True
then I can click anywhere within the start or end token to highlight the brackets. 

So that only leaves the problem of the bracket highlighting even when there is no matching bracket.
I'll look into code behind to fix that.