Cursor Position for Bracket Match of keywords

SyntaxEditor for Windows Forms Forum

Posted 7 years ago by Mike Dempsey - Sr. Developer, Teradata Corp
Version: 12.1.0289

I finally have time to look into the workings of Syntax editor (with plans to migrate from a Codemax [COM] implementation) and I immediately noticed 2 strange things about your bracket matching implementation.

This may be specific to Dynamic languages (I am hoping to use Dynamic languages as I have to support 12 different SQL dialects and I really dont want to have to code 12 different code based languages. But I don't currently see any way to differentiate between tokens that are used in 2 contexts.)

It seems that you highlight the brackets ONLY when the cursor is immediately before the Start 'token' or immediately after the End 'token'. This is no problem if the tokens are only one character long but it is very non-intuative if the tokens consist of multiple characters.   eg.  CASE ... END CASE

Users expect the brackets to be highlighted if they click ANYWHERE within the token.
(The only exception would be either before or after the token. Using your current logic it would not highlight after the Open token or before the Close token. Personally I prefer consistancy so I would prefer it to work either before or after [but not both] both tokens)

The second oddity is that the token is highlighted even if the corresponding token does not exist.
For example, if I omit the 'end case' in the example above and then place my cursor immediately before the starting 'case' token then the token is highlighted ... even though there is no match for it.

That rather defeats the purpose of brace matching. Users often click on a start keyword to verify that the matching end token exists. The end token may not be currenty visible, but if the start token is highlighted they assume it must exist without scrolling down to check. 

Is there any way to correct this behaviour when using a dynamic language.

Can it be corrected if I write my own code based language?


Comments (5)

Answer - Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA

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.

Actipro Software Support

Posted 7 years ago by Mike Dempsey - Sr. Developer, Teradata Corp

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
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.) 


Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA

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.

Actipro Software Support

Posted 7 years ago by Mike Dempsey - Sr. Developer, Teradata Corp

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.


Answer - Posted 7 years ago by Mike Dempsey - Sr. Developer, Teradata Corp

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.

The latest build of this product (v2018.1 build 0341) was released 3 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.