By default, ctags generates scope information using ``` parent_kind:A::B::C ``` where `A::B::C` is the scope of the parent tag. This is a bit problematic when parsing such fields because we have to compare the `parent_kind` value against all valid kinds of the language and if it matches, it means that what follows is the scope. This slows down parsing of such tags and also requires that `parent_kind` is really a valid kind for the given languages.
ctags can also add extra "scope:" prefix to this field when using the sZ field specification option on the command line: ``` scope:parent_kind:A::B::C ``` This way, the scope field can be detected easily by comparing against "scope:" which speeds up parsing. Also, the parsing code doesn't care about the value behind "scope:" so "class" can be used also for languages that don't have the "class" kind.
I haven't regenerated the tag files to avoid a big diff but the result will add "scope:" for every tag's scope field and this should be done separately.
By the way, this could help anyone reviewing #3049 understand what's going on. Parsing scope fields with the `scope:` prefix happens here:
https://github.com/techee/geany/blob/f49b19f3bfe61cf7ae27075f28ec5bd7c570a1b...
If scope is not obtained this way, the code tries to go through all the fields which weren't parsed before and check if they start with a kind name of that language. If they do, the field is considered to be scope, see:
https://github.com/techee/geany/blob/f49b19f3bfe61cf7ae27075f28ec5bd7c570a1b... You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3592
-- Commit Summary --
* Prefix generated scope field by the "scope:" prefix
-- File Changes --
M scripts/create_tags_helper.py (6)
-- Patch Links --
https://github.com/geany/geany/pull/3592.patch https://github.com/geany/geany/pull/3592.diff
I've added this to the 2.0 milestone, but, strictly speaking, it's not absolutely necessary if it's considered problematic for some reason. The tag files will be parsed alright by https://github.com/geany/geany/pull/3049, parsing will just be slower and unnecessarily inefficient.
Having had a look at #3049 I get the point. But IIUC it must only be merged after #3049 is, otherwise it'll make things rather worse as the current ctags file parser don't understand that field (it could be made to, but I guess it's not the point :))
But if uctags still generates the `parent_kind:A::B::C` form the problem will still apply in the case of ctags generated files without `sZ` so needs to still be able to read those files. And document the ctags option as recommended somewhere.
How "slow" is it in reality? After all tags are only read once, even seconds is likely to be acceptable.
But if uctags still generates the parent_kind:A::B::C form the problem will still apply in the case of ctags generated files without sZ so needs to still be able to read those files. And document the ctags option as recommended somewhere.
The documentation is a good point, I'll write something.
How "slow" is it in reality? After all tags are only read once, even seconds is likely to be acceptable.
I haven't benchmarked that, it probably just "doesn't feel right" than being some real problem.
@elextr Would you mind having a look at the update of geany.txt I made in https://github.com/geany/geany/pull/3049 if it looks alright to you?
Purple editors pencil has been deployed :-)
How "slow" is it in reality? After all tags are only read once, even seconds is likely to be acceptable.
I just tested it and it's actually about the same both with and without `scope:`. Roughly 1 million tags per second.
So while I still think the patch is worth applying, it can wait after 2.0.
Closed #3592.
github-comments@lists.geany.org