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...
The guilty is the call to parseImports() in tagmanager/ctags/python.c.
I have disabled this line and this fixes the problem. Now, Python navigation is behaving correctly.
I tried to make it configurable but it seems to be rather complicated to reach (in a clean way) the ctags code from Geany's configurator.
Would it be possible to only delete the line in Geany's source code ? or is anyone more interested in being redirected to the import line rather than the actual definition ?
Thanks.
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.
Not parsing the imports doesn't solve the problem, it rather just makes it not happen. I personally like parsed imports and also want to get to the real symbol definition instead of the import, obviously.
I'll try to recapture what I've found once and/or debug it again and then ask Colomban for his great wisdom about tag parsing :).
Would it be possible to only delete the line in Geany's source code ? or is anyone more interested in being redirected to the import line rather than the actual definition ?
No, surely not.
Regards, Enrico
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
Le 26/01/2014 13:10, Enrico Tröger a écrit :
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 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.
[...]
@Colomban: are you fine with this new category? Then I would commit the changes.
Yeah sure. It's a bit of a hack, but it may be better than a python-specific code path in goto_tag(), so sure, go ahead.
Regards, Colomban
On 06/02/14 17:59, Colomban Wendling wrote:
Le 26/01/2014 13:10, Enrico Tröger a écrit :
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 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.
[...]
@Colomban: are you fine with this new category? Then I would commit the changes.
Yeah sure. It's a bit of a hack, but it may be better than a python-specific code path in goto_tag(), so sure, go ahead.
Ok, great. Committed.
@Johann: fixed in GIT master, feel free to try it.
Regards, Enrico
Thanks a lot.
I just built the trunk and it seems to work
2014-02-08 10:28 GMT+01:00 Enrico Tröger enrico.troeger@uvena.de:
On 06/02/14 17:59, Colomban Wendling wrote:
Le 26/01/2014 13:10, Enrico Tröger a écrit :
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 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.
[...]
@Colomban: are you fine with this new category? Then I would commit the changes.
Yeah sure. It's a bit of a hack, but it may be better than a python-specific code path in goto_tag(), so sure, go ahead.
Ok, great. Committed.
@Johann: fixed in GIT master, feel free to try it.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel