On 09/01/14 23:00, Enrico Tröger wrote:
On 09/01/14 21:57, Johann SAUNIER wrote:
Hi all,
Code navigation in Python language is a pain due to the fact that the action "go to symbol definition" on classes or methods don't go to the actual definition, but rather heads to the import line at the top of the file. I am a bit surprised that no one complains about that...
I'm annoyed by this as well, beaten by it almost every day.
The guilty is the call to parseImports() in tagmanager/ctags/python.c.
Ah, my code :(. More seriously, I once debugged this quite a bit and the import parsing is only the symptom, the real cause is deeper. Unfortunately, I don't remember all the details because at some point I gave up on this issue because I didn't find a way to fix it.
I had another look at the problem and actually found quite a good solution.
Attached are two patches to address this. The first patch is just a requirement, the second one the actual fix.
The story: when Geany tries to find and go to a tag, it first looks in the current file, if no success, then in all other open files. This is why Python imports always got precedence over the real class implementation, because the imports are always in the current file (from Geany's point of view). However, Geany already does exclude certain kind of tag types, namely C forward declarations and extern variables. Currently Python imports are parsed as tags of kind "namespace". At the time of writing the parsing code, I found this quite suitable. Now, the second patch change the tag kind to "externvar" simply to match the exclude patterns in symbols.c:goto_tag() and then the import statements in Python code are ignored when using 'Goto tag'.
To still get the Python import statements listed in the Symbols tab as Imports, I added a new symbols category "External variables" in the first patch and map it to "Imports" for Python. So far, the tag kind externvar is only used by Basic, C, D and now Python (according to grep over tagmanager/ctags/*, in Basic it is even only defined but never used). So, this new category has low impact: in C and D files, variables defined as extern will show up in that new category, before they were sorted in "Other". For Python files, import statements will be listed in "Imports" as before but behind the scenes their tag kind is externvar and not namespace.
@Colomban: are you fine with this new category? Then I would commit the changes.
Regards, Enrico