[Geany-Devel] Python tags

Enrico Tröger enrico.troeger at xxxxx
Sun Jan 26 12:10:42 UTC 2014


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

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01_geany_add_symbol_cat_externvar.patch
Type: text/x-patch
Size: 1293 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20140126/f60910a8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02_geany_change_python_import_tag_type.patch
Type: text/x-patch
Size: 1190 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20140126/f60910a8/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.geany.org/pipermail/devel/attachments/20140126/f60910a8/attachment.pgp>


More information about the Devel mailing list