As explained in the comments I added, for some reason tok.lineno is larger than the number of elements of splittext (which is the vector containing the lines of the local variable text).
For example, it happens that splittext has value
[u'&P393071 = SAAB 17, 1', u'#p']
and tok.lineno has value 11, so we were trying to access splittext, which has length 2, at element 10. Note that splittext appears to be somehow "corrupted", while self.lexer has the full list of tokens of the same file. I honestly don't understand why this happens.
The work around (it's not a real fix!) I'm proposing here is to check that tok.lineno is equal to or less than the length of splittext before trying to access the line, and if not then set mylength to 0 (which effectively doesn't highlight anything). As an alternative, we might just continue if the check if false.
I'm mildly confident that the issue addressed by this PR happens only in tests because multiple files are quickly opened one after each other. I never saw this issue while using Nammu. In this sense, this is a more concrete way to address random failures in test than #397.
As explained in the comments I added, for some reason
tok.linenois larger than the number of elements ofsplittext(which is the vector containing the lines of the local variabletext).For example, it happens that
splittexthas valueand
tok.linenohas value11, so we were trying to accesssplittext, which has length 2, at element 10. Note thatsplittextappears to be somehow "corrupted", whileself.lexerhas the full list of tokens of the same file. I honestly don't understand why this happens.The work around (it's not a real fix!) I'm proposing here is to check that
tok.linenois equal to or less than the length ofsplittextbefore trying to access the line, and if not then setmylengthto 0 (which effectively doesn't highlight anything). As an alternative, we might justcontinueif the check if false.I'm mildly confident that the issue addressed by this PR happens only in tests because multiple files are quickly opened one after each other. I never saw this issue while using Nammu. In this sense, this is a more concrete way to address random failures in test than #397.