I followed your suggestion and changed the output format of the tags file to ctags.

Well, it isn't something I'm one hundred percent sure we should do, but rather something I wanted to discuss. Also, I had something different in mind - to use ctags directly to generate the tag files instead of doing it by ourselves in the script (so there wouldn't be the need for messing with the ctags file format on our side). I haven't checked what exactly the script does and whether something like this would be possible though - what do you think?

Regarding whether to create the Python with ctags instead of this script:
I gave it a try and there are a couple of differences and problems with ctags:

ctags will find way more tags, many tags we are not interested in for a global tags file like private methods and special methods (_* and __*) and variables. Those could be filtered out afterwards though.
ctags will add the path and search pattern or line numbers of the source file which doesn't make sense for global tags. Those could be filtered out afterwards though.
Classes found by ctags have no signature (the one of the corrsponding __init__ method) while the ones of my script have
ctags will include deprecated tags as well while my script filter them out (even more than the manually defined ones)

Overall, for me, the generated tags of the script look cleaner and more sane than the ctags ones.

For reference, the ctags command I tried:

ctags \
	--exclude=encodings \
	--exclude=dist-packages \
	--exclude=distutils \
	--exclude=idlelib \
	--exclude=ensurepip/_bundled \
	--exclude=test \
	--exclude=Tools \
	--exclude=turtledemo \
	--exclude=site-packages \
	--exclude=turtle.py \
	--exclude=asyncio/windows_utils.py \
	--exclude=asyncio/windows_events.py \
	--exclude=antigravity.py \
	--exclude=ctypes/wintypes.py \
	--recurse \
	--languages=Python \
	--excmd=number \
	--totals=extra \
	--fields=+tS /home/enrico/.pyenv/versions/3.10.8/lib/python3.10

While playing with the ctags command, I noticed I erroneously set a class' base as parent which is wrong in this context and methods used the wrong kind. Those are fixed.

Also, if we want to use the ctags format, we should merge #3049, otherwise not all the fields are parsed correctly.

To the topic of pros/cons of using the ctags file format, these are the advantages I can think of:

* we could use `ctags` directly to generate tag files as mentioned above

* currently the tagmanager format doesn't escape characters 200-215 which could break tag file parsing (it is fixable though)

* `ctags` file format is "standard" while the tagmanager format is "proprietary" to geany (and also binary which isn't very nice)

On the other the cons of the ctags format are:

* the tag files are bigger

* they are slower to parse

* command line `ctags` may be less flexible in generating tag files than some specific-purpose script

* if Geany ctags is out of sync with the `ctags` command-line that produces tags, we may not be able to read all of the tags

I'd prefer the ctags format because, as you say, it's the standard format and probably less error prone than the custom tagmanager format.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.