If a line contains non-ASCII characters (eg. in a string literal), declarations and uses later in that line get shifted from their correct locations. Example: code = 502 print("Código: %d" % code, file=sys.stderr) "ode," is highlighted as a use of the "code" variable. "ys.std" is highlighted as a use of "stderr". "ys." is highlighted as a use of "sys", which overlaps with the "stderr" range so you can't actually hover it. Deleting the letter "ó" and waiting a second for the auto-reparse makes the ranges become correct.
I spent a little while looking at this. The cause is that the CPython parser (used by KDevelop) returns all offsets in UTF-8 bytes, while the KTextEditor API uses actual characters. Anything represented using >1 byte in UTF-8 thus causes the offset. The only way I see to fix this would be to scan for multi-byte characters and do yet another set of range fixups, which would be quite expensive while benefitting very few scenarios. (we can't remove such characters before feeding the parser, because they can appear in docstrings or even identifiers) The other alternative would be to have our own parser (again); that's clearly not worthwhile for this alone, but there's already a lot of ugly code to workaround various limitations/lossiness and statements by the CPython devs (e.g. https://bugs.python.org/issue32911#msg313698) suggest it's only likely to get worse.