Thanks for cleaning up the tests after me!

Yeah, this might be another bug in the QtCreator (already fixed one crash in their highlighting implementation). They asked me to not put much effort because that code it deprecated anyway in favor or KDE lib. But they just released Creator 4.8.0 and I do not expect any major updates in the nearest feature. So providing simple workaround in the XML should be good enough. Thanks for the quick review as always!

Thanks for the fix, yes it is valid. Previously "end" was used as a standalone keyword, but keyword requires space after the word. Now it used in StringDetect to detect cases like "end sub" and "endsub" in the same rule.

Increased version number.

This language does not have folding test. I did not provide validation for it before. Should I do that?

Thanks for the review. Btw, is there any chance to preserve my name/email in the final commit?

Thanks for catching this. Did re-run tests locally, seems no other issue remaining. Please check.

Replaced missing "code" attribute with "g".

You can find my credentials at the beginning of the file I added in this patch: data/syntax/brightscript.xml

@ngraham, so I have to match commit authors in syntax-highlighting Git project against that list? Curious whether all those people have rights to push patches particularly into this project. Still it feels like this is not an easy task to do that manually, so I would rather annoy you guys in this message thread with my push request (-:

Thanks a lot for helping me with this! One last question: how do I know that patch was finally merged, by periodically checking the github mirror git repository? https://github.com/KDE/syntax-highlighting.git

I do not have a KDE commit account, so I guess I need your help to integrate this patch.

Just double checking whether any additional actions required from my side or 'landing' a patch means it will be a part of the next release automatically.
If so then where I could find a release roadmap?
Thanks in advance!

There are various reasons I was using 1-element keyword lists instead of StringDetect:

1. keyword properly recognizes value surrounded by non-word characters, StringDetect does not.
2. BrightScript language is case insensitive, adding insensitive="true" to every single StringDetect is too verbose in my case.

Changed syntax license to MIT.