This is a tracking bug where we are with universal-ctags syncing regarding individual parsers. After https://github.com/geany/geany/pull/1160 gets in, the work on merging the parsers can start.
If someone wants to merge some of the parsers, it would be best to drop a line here so people don't do the same work in parallel.
Below is the state of individual parsers -> shows the general direction of from where to where the changes should be brought. <-> means changes will probably be necessary in both Geany and uctags parsers.
**basically merged**
- [ ] asm - [ ] cobol - [ ] css - [ ] erlang - [ ] json - [ ] objc
**waiting for varType in uctags**, see https://github.com/universal-ctags/ctags/issues/862 (simple to merge)
- [ ] go (Geany->uctags) - [ ] rust (Geany->uctags)
**normal diffs**
- [ ] basic (uctags->Geany) - [ ] diff (uctags->Geany) - [ ] fortran (uctags<->Geany) - [ ] html (Geany->uctags) - [ ] jscript (uctags<->Geany) - [ ] lua (uctags->Geany) - [ ] make (uctags->Geany) - [ ] pascal (Geany->uctags) - [ ] perl (uctags->Geany) - [ ] php (uctags<->Geany) - [ ] ruby (uctags->Geany) - [ ] sql (uctags->Geany) - [ ] tcl (Geany->uctags)
**big diffs**
- [ ] python (uctags->Geany) - [ ] r (uctags<->Geany) - [ ] sh (uctags->Geany) - [ ] verilog (uctags->Geany)
**unmergable diffs**
- [ ] latex (uctags) vs tex (Geany) - different parsers - haven't checked what they do and if they should be treated as a parser of a single language or not - [ ] matlab (we have regex-based parser, uctags has hand-written one - we should probably grab the uctags one) - [ ] VHDL (different parsers from different people - uctags parser contains more LOCs so it's probably better :-) - [ ] c.c (meh)
**extra parsers in Geany** abaqus, abc, actionscript, asciidoc, conf, docbook, haskell, haxe, markdown, nsis, powershell, rest, txt2tags
**extra parsers in uctags** ada, ant, asp, awk, beta, clojure, dbusintrospect, dosbatch, dts, eiffel, falcon, flex, glade, jprop, lisp, maven2, myrddin, ocaml, perl6, plist, protobuf, relaxng, rex, rpmspec, rst, scheme, slang, sml, svg, ttcn, vim, windres, xslt, yacc
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1162
Yay a planning and management issue :)
Extra parser in uctags also the new C/C++ one.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1162#issuecomment-237532341
The Python one should be grabbed without too much worrying on fixes on our side: I wrote it especially to fix all the crap and bugs, and it was initially meant for Geany. Also, AFAIK there was no fix on our side that weren't ported to U-CTags eventually.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1162#issuecomment-237534692
I've updated the description a little towards a slightly more optimistic picture. After looking at it a little more, I think c.c is mergeable, it will just be a lot of work. I also moved R to "normal diffs" because it's not that bad. Finally, in "extra parsers in uctags" I kept only those for which we have a filetype in geany and which are interesting for us.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1162#issuecomment-238094094
I suggest you probably don't want to merge the markup language parsers (Asciidoc, markdown, rest, txt2tags) from Geany to uctags, they are actually used to define the document outline rather than symbols as such.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1162#issuecomment-238113305
I suggest you probably don't want to merge the markup language parsers (Asciidoc, markdown, rest, txt2tags) from Geany to uctags, they are actually used to define the document outline rather than symbols as such.
But this is the case of HTML and latex in uctags already so I think it's fine.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1162#issuecomment-238116076
What is the status of this? No uctag has been merged into geany?
@Akronix there is a very big pull request #1263? waiting for someone to have sufficient time to review and commit it.
Not sure which branch to do a pull request of the commit below; @elextr suggested I keep my changes in a separate branch https://github.com/geany/geany/compare/master...quipa:lisp_dialect_parsers
I'm thinking about this issue.
A. copying all parsers that are in geany and not in u-ctags to u-ctags. B. making geany using u-ctags parsers only if they have enough quality (as default, see C.) C. providing the way to override to geany: if geany doesn't want to use a parser implementation in u-ctags, geany should be able to use its alternative implementation. D. writing/running acceptance tests that verify the quality of u-ctags code
I'm studying ctags-api.[ch] and trying to understand the geany side expcetations to u-ctags.
@masatake Geany is slowly moving towards being able to use as much upstream ctags unchanged as possible, see #1263 (merged) and #2018.
But nobody has dared to look at Geany's c.c yet :)
It has a lot of history as it was changed significantly independently during the period that ctags was unmaintained. I think it even got an extra {} language in it.
@elextr, thank you for replying.
I would like to know the workflow of geany side. Consider parser for X is alrady merged. It means X is maintained u-tags side, and geany imports X from u-ctags. I added a very interesting feature or performance improvements to X yesterday. You may want to re-import the code again. What will you do in such case?
My image is following: 1. git pull at your local u-ctags copy. 2. cp X.c in u-ctags to Geanys' ctags/parsers directory 3. Doing test or something?
I would like to know the detail of steps.
The basic PR that re-organised things to allow that (#1263) was only committed late last year but it was then several years old and #2018 just brings it more up to date, so we don't actually have a defined workflow yet.
I was thinking something similar to the way we manage Scintilla and its lexers, where we import changes when a release happens so its stable, not during development.
There is a script in geany/scripts that copies the Scintilla lexers we use into Geany IIUC and I expected thats what we would do for ctags as well. Ctags may be easier because its git, Scintilla is hg.
Many of the tests from ctags are also imported and are tested as part of the Travis CI that runs on each Geany PR, so the PR to incorporate a new ctags release would get tested automatically.
@b4n and @techee probably also have opinions here too.
Again, I suggest using git-subtree to import u-ctags, then make our changes on top (build system, remove/swap parsers, geany-specific changes). Following that, we can import new versions with a single "git subtree pull" command while maintaining our changes.
Hi, just discovered this issue while trying to get ocaml code parsed in geany. Definitely seems the good place to ask: would it be possible to merge u-ctags ocaml parser?
@CyberDomovoy not really. Adding an individual language is a separate issue from any long term workflow issues. If someone makes a PR to add Scintilla lexer (if it exists) and ctags parser and the integration with Geany then it can be looked at.
I'm closing this issue as #3170 contains more up-to-date information.
Closed #1162.
github-comments@lists.geany.org