In these cases, the magic-method's name doesn't appear in the code, so we highlight the opening paren or square-bracket. ``` mc = MyClass() # <- `(` links to MyClass.__init__ mc[2] # <- `[` links to MyClass.__getitem__ ``` In some cases, completely the wrong character is highlighted: ``` class MyClass: def __call__(self): return 12 def __getitem__(self, key): return 1.2 foo = {} foo['aaa'] = MyClass() bar = foo['aaa'][2] # First 'a' is highlighted instead of second '[' baz = foo['aaa'](2) # ')' is highlighted instead of '(' # Not sure why these behave differently ``` This seems particularly common after string literals.
This is a quite frequent issue, and should definitely be fixed before 5.1 final.
The very frequent errors were my fault; I introduced a bug in https://cgit.kde.org/kdev-python.git/commit/?id=94ab1ee Fixed that in https://commits.kde.org/kdev-python/9ba8942 There are remaining glitches if: - The bracket doesn't immediately follow what's being called: `foo (arg)` <- the space is highlighted. Uncommon. - The expression being called/subscripted has an incorrect range: ``` class A: def __call__(self): return 10 aaa = [A()] bbb = aaa[000]() # The middle '0' is highlighted. ``` I think these have always existed, but the second type is more common after 9ba8942 because we show uses after many more subscript expressions, which are most commonly broken.
Nice, looks much better now. Thanks. You can also use CCBUG:12345 to CC a bug with a commit without closing it.
Git commit 2049938304a0a8b65240d551117c8c169ee60ece by Francis Herne. Committed on 25/12/2016 at 10:56. Pushed by flherne into branch 'master'. Set mostly-correct endCol on numbers, single-quoted strings and subscripts. Before, endCol of number/string literals was identical to startCol; endCol of subscripts was the end of their slice node. This caused highlighting glitches when trying to position things after them. Unaddressed: - Triple-quoted (particularly multiline) strings. This gets length 2 (inc. quotes) or does nothing, which is no worse than at present. Such strings are very unusual inside expressions where we care about the length. - Space between the end of a slice and the closing bracket of a subscript: `a = b[ 2 ]`. Recommended against by PEP-8, but happens. This should fix most remaining examples of bug 373850. M +31 -1 parser/astbuilder.cpp https://commits.kde.org/kdev-python/2049938304a0a8b65240d551117c8c169ee60ece
Git commit 458f64330f89187d8efd558da550974c2777904c by Francis Herne. Committed on 01/01/2017 at 21:32. Pushed by flherne into branch '5.1'. Yet more range fixes. RangeUpdateVisitor was only run after completion of RangeFixVisitor. When RangeFixVisitor modified both a node and a non-parent ancestor of that node, the ranges of the intermediate nodes weren't updated and so the ancestor's fix didn't take the previous fix into account. Move the functionality of RangeUpdateVisitor into RangeFixVisitor so changes are propagated in time. There was a bug in the `findString` regex that prevented it working for empty strings. Switch to QRegularExpression (I should have used it originally) and use a better regex. Correct the ranges of byte and (python36) f-string literals, in addition to normal strings. The 'b'/'f' still isn't coloured, but afaik that's KSyntaxHighlighting. Hack comprehensions, lists and tuples in a similar way to subscripts; far from reliable, but ok for single-line expressions following PEP-8. M +63 -36 parser/astbuilder.cpp https://commits.kde.org/kdev-python/458f64330f89187d8efd558da550974c2777904c
This now works fine in all common cases, there's not much room for improvement unless we can get accurate range support into the parser somehow.