> > 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.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3039#issuecomment-1312720245
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3039/c1312720...@github.com>
