When changing the level* of long comments or long strings, subsequent code is incorrectly highlighted as comment or string respectively. This happens regardless of how many levels you add or remove, as long as it is a different level than it was at when the script was opened.
*) amount of “=” characters between the [[ and ]], i.e.
-- [[ long comment ]]
-- [==[ long comment of level 2, so that i can put ]] safely in the comment ]==]
local s1 = [[ long string ]]
local s2 = [====[ same concept, long string of level 4 ]====]
Depiction of problem:
After I add ‘=’ to the front and back of the long comment definition, it should not be highlighting the code below it on line 7 in comment color.
After I add ‘==’ to the front and back of the string definition, it should not be highlighting the code below it on line 7 in string color.
Additional notes:
Reloading the script fixes the highlighting into what it is expected to do. However, if you change the level of the comment/string again (adding/removing "="s), the highlighting is messed up until you reload the script once more.
When creating a new long comment / string in a script, the highlighting is correct until you start adding levels (adding '='s).
and NOW it’s broken. Apparently if you start it in one style, and then switch to the other without completely erasing all the text to the --'s, it will glitch
Can confirm @ColdSmoke’s findings that this only happens when the =s are changed. If the code is pasted, the syntax coloring is fine, but when an = is removed or added, the bug occurs.
