Matching EndScope token with LookAhead gets skipped on edit!

SyntaxEditor for Windows Forms Forum

Posted 14 years ago by mbren
I have been getting unpredictable results on certain scopes when the text around the scope is edited. Editing in certain locations can cause a matching EndScope character sequence to be skipped over – resulting in an open scope or a misaligned scope. I have managed to put together a reproducible example to outline the problem.

I will use the following simplified demonstration scope to outline the issue (it opens with a ‘=’ character and must terminate if it encounters ‘cat’, ‘dog’ or ‘tiger’ at the start of a new line – independent of its indentation level).
<State Key="Tester">
        <Scope BracketHighlight="True">
            <ExplicitPatternGroup Type="StartScope" TokenKey="OpenTester" PatternValue="=" />
            <RegexPatternGroup Type="EndScope" TokenKey="CloseTester"
                PatternValue="{LineTerminatorMacro} {WhitespaceMacro}*" LookAhead="cat|dog|tiger" />
If this is applied to an already existing document (ie. not typed into the editor while the language definition is applied – the reason for this will become clear) such as the one below (note that all lines are tabbed in at least once – this will also become clear), everything is parsed correctly.
        first scope
    interscope text 1
        second scope
    interscope text 2
        third scope
All three scopes are recognised. But if you enter or remove text from the line directly below either ‘cat’, ‘dog’ or ‘tiger’ you will notice that the scope that ended before the preceding LookAhead match has now opened up and is either closed by the following scopes EndScope token or left open if it was the last scope in the document. (eg. if you add or remove text from the line containing ‘interscope text 1’, the first scope now begins at the first ‘=’ but now ends before ‘dog’).

If text is added to the original scope in the line preceding the now skipped LookAhead match (in the last example text would be entered in or around the line containing ‘first scope’) or added to the line containing the now skipped LookAhead match (in the last example on the line containing ‘cat’) then the scope returns to its original state and is aligned correctly.

If you now try to type the text from the example document into a blank editor with the scopes rules applied, as you type into the line after the word ‘cat’, ‘dog’ and ‘tiger’ (or as smart indent tabs are added to the following line on pressing the enter key after the word) you will notice the scope is lost each time resulting in a endlessly open scope each time you try to type a new scope. If you cut and paste the text of the misaligned scopes back into the editor you will find the text is now parsed correctly and all 3 scopes are correctly aligned.

I have noticed that this only seems to occur if the LookAhead match is preceded by at least one whitespace character.

Is this a known issue? Is there a possible work around? I am assuming it is a bug and am desperately hoping it is not ‘by design’ and can be resolved.

Once again thank you.

Comments (2)

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Thanks for the excellent repro steps. It is indeed a bug that we now have fixed for the upcoming maint release.

Actipro Software Support

Posted 14 years ago by mbren
No Problem, thanks for fixing this.
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.