Parsers for R and verilog from ctags are token-based instead of our line-based parsers and are definitely superior and all development should go towards these parsers.
The sh parser is not token based but the uctags version seems to handle more things.
Other 2 parsers which I think we should eventually adopt are VHDL and tex parsers (both are token-based) - they generate a slightly different set of tags and tag mappings should be adopted to those for the sidebar so I skipped them for now.
Finally, I tried also switching to uctags `c.c` for java, D and C# but our c.c seems to be actually better there. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3035
-- Commit Summary --
* Use uctags R parser * Update R kind mappings * Use uctags parser for sh * Update mappings for sh parser * Use uctags verilog parser * Update mappings for verilog parser * Update verilog unit tests * Add R and Verilog to languages reporting context
-- File Changes --
M ctags/Makefile.am (7) D ctags/parsers/geany_r.c (177) D ctags/parsers/geany_sh.c (110) D ctags/parsers/geany_verilog.c (332) A ctags/parsers/r.c (1470) A ctags/parsers/r.h (111) A ctags/parsers/sh.c (490) A ctags/parsers/verilog.c (2024) M src/tagmanager/tm_parser.c (14) M tests/ctags/bug1111214-j-chan.v.tags (4) M tests/ctags/traffic_signal.v.tags (24)
-- Patch Links --
https://github.com/geany/geany/pull/3035.patch https://github.com/geany/geany/pull/3035.diff
@techee pushed 1 commit.
ce6de3bad92344c689bdf5667a115cd8e4ba13ac Merge branch 'master' into different_parsers
@techee pushed 1 commit.
53a5b7df370a08cf80a3422d6bc77854e9fb6804 Merge branch 'master' into different_parsers
but our c.c seems to be actually better there.
yeah, some contributors were improving them when there was no upstream. But they stopped before an upstream became available. Probably would be nice to share upstream.
yeah, some contributors were improving them when there was no upstream. But they stopped before an upstream became available. Probably would be nice to share upstream.
The "better" part is mostly the ability of Geany's c.c to give return type of functions and types of global variables which is missing in the upstream c.c. The problem is that this is done in a rather hacky way to just record the part that might be a type in the preprocessor, keeping it completely unparsed, cleaning it from possible comments inside, and then presenting it as a type. The upstream c.c. is using a different preprocessor (`cpreprocessor.c` like the cxx parser, not the old `lcpp` that Geany uses for c.c) and I'm not sure they would be interested in the solution Geany uses.
I'm not sure they would be interested in the solution Geany uses.
Ok, fair enough, its only nice to share if its any good.
Ok, fair enough, its only nice to share if its any good.
Once all the parsers are merged, I'm planning to create a new issue replacing #1162 where I would describe what is remaining in the sync and what the differences are in the parsers and possibly involve the maintainer of uctags in the discussion.
Once all the parsers are merged
To clarify, I meant the currently pending pull requests here.
I meant the currently pending pull requests here.
Does that include the ones with the [Here be Dragons](https://en.wikipedia.org/wiki/Here_be_dragons) (`tag-manager`) :smile: label?
Does that include the ones with the Here be Dragons (tag-manager) 😄 label?
No, just those worry-free "ctags parser" 10KLOC+ PRs :-).
Merged #3035 into master.
github-comments@lists.geany.org