The question now is whether not to switch to the ctags file format for the languages which have identical implementation (and therefore kind letters) both in Geany and ctags. I don't know what the script does exactly but if we switched to the ctags file format, wouldn't it be sufficient to run the ctags binary on the corresponding directory with sources?

The "proprietary" half-binary format is still useful for our unit tests since it already contains ctags kinds mapped to our internal representation so we can verify this mapping is done correctly. But for the tag files shipped with Geany I think we are more or less ready to switch to the ctags file format and suggest users to use ctags to generate it.

What about the other languages in c.c?

Yes, vala for instance is missing and those will still have to be generated by Geany if users want them. But all the parsers for the tags under `geany/data/tags` will be the upstream ones.

@eht16 pushed 2 commits.

916cefdc04684568bab968085551e337b2afdea1 Remove unused code c1387f831dc24eb58fa228839cd1de19dfacaeff Change the generated tags file to ctags format

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?

Also, if we want to use the ctags format, we should merge https://github.com/geany/geany/pull/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 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.

+1

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.

...

Classes found by ctags have no signature (the one of the corrsponding **init** method) while the ones of my script have

Curious about this one - how does it behave when there are multiple corresponding `__init__` functions with a different signature? Will it pick just one of them for calltip? I'm asking because we now have this code

https://github.com/geany/geany/blob/8f35d3342df724145ee9a6873e4ed3a18446211d...

which can look up all `__init__` functions for a class and display a multi-calltip (with arrows on the side to scroll among the found calltips) containing all the constructors.

In Python, there is no point in having multiple `__init__` methods. While technically possible, it makes no sense because the latter method overrides the previous one. The script here would probably pick one of them, I don't know which one, it is decided by the `inspect` library.

One more thing - wouldn't it make sense to factor-out the tag writing code to a separate file so it can be reused by other tag writing scripts? For instance, there's also `create_php_tags.py` which I think could reuse this code too. And maybe this tag-writing code could be configurable to either output the ctags format or the tag manager format - I can imagine that having the tagmanager format could be useful for debugging. What do you think?

Sure we can do that. But IMO both ideas would be better handled in seperate PRs to not blow this one even more.

In my tests the tags worked but I don't know the format that well, so it would be cool if you could spend a look at it, @techee.

I just had a look and it looks good to me.

@eht16 commented on this pull request.

# If called without command line arguments, a preset of common Python libs is used.

# # WARNING -# Be aware that running this script will actually *import* modules in the specified directory +# Be aware that running this script will actually *import* all modules given on the command line # or in the standard library path of your Python installation. Dependent on what Python modules # you have installed, this might not be want you want and can have weird side effects.

Amazing, someone actually read the docs :). Thank you for spotting, fixed.

Merged #3039 into master.