So I tried to just get the regex parser compile and run but it turned out that it requires so many changes in ctags itself that it's just impossible to perform without the complete ctags sync. So the first patch is a huge blob which gets all the upstream changes (no way to get this more granular) on top of which I applied the Geany-related changes. Regex parsers using GNU regex work, at least on linux (not sure about Windows - someone has to get it compile there if it doesn't work).
This was hell a lot of work and something I don't want to do in the future in this form. So in the subsequent patches I tried to minimize Geany-related diffs to the absolute minimum, even if it meant adding and compiling more uctags code (which we'll never actually use). I'd say the result is quite nice, the diffs are really minimalistic and easy to locate in the code. The upstream commit against which this is made is
7dd02539554a81aa39b49ce8df9d4511f92d9f4f
which is already several months old but this is the one against which we have the parsers synced (in fact, it's against https://github.com/techee/ctags/commit/915d69794cd90af9a2e577dd57dd888341eef... to have this fix applied). The best way to review this pull request is to make a diff in meld against this commit in uctags - the diff is really small - and also having a look at the patches excluding the first one which is just unreviewable.
I'd really like if this could get merged soon because I don't want to get again to the state where I have to merge multi-year diffs from uctags. My proposal is that I'd prepare a patch at the beginning of every Geany release cycle which syncs it with uctags (by just taking the current uctags code and applying Geany diffs on top of it) so it gets tested during the development cycle. If we make releases 3 times a year, the diffs shouldn't be so huge and much more easily manageable.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2132
-- Commit Summary --
* Sync with upstream ctags * Enable Cobol test * Rename Geany ctags diff markers * Store varType inside typeRef[1] * Add all ctags writers to eliminate some geany diffs * Move bufferOpen() to parse.c to eliminate diff in read.c/h * Reduce diff size in fileNameMatched() * Reduce number of diffs in main.c * Use upstream mbcs.h * Reduce number of diffs in parse.c/h * Move diffs together in entry.c/h * Move isIgnoreToken() to lcpp.c/h which we don't sync with uctags * Eliminate diff in options.c by adding interactive_p.h * Reuse createTagsWithFallback1() for Geany * Eliminate bufferOpen() * Make sure all functions/global vars added to ctags have the "geany" prefix * Eliminate diff in runParserInNarrowedInputStream() * Eliminate diff in promise.c by manually enabling Xtag during initialization * Add some comments * Make sure all kinds are enabled in ctags for all languages * Use the builtin ctags writer functionality to pass tags to Geany * Remove some diffs from parse.c * Reuse the functionality of createTagsWithFallback() * Simplify various ctags-api.c implementations using existing ctags functions * Fix ctags warning because of cobol parser f/file kind which is reserved * Add simple ActionScript test
-- File Changes --
M configure.ac (2) M ctags/Makefile.am (34) M ctags/main/args.c (6) R ctags/main/args_p.h (6) A ctags/main/colprint.c (295) A ctags/main/colprint_p.h (37) M ctags/main/ctags-api.c (134) M ctags/main/ctags-api.h (4) M ctags/main/ctags.h (8) M ctags/main/debug.c (102) M ctags/main/debug.h (28) M ctags/main/dependency.c (349) M ctags/main/dependency.h (42) M ctags/main/e_msoft.h (10) M ctags/main/entry.c (682) M ctags/main/entry.h (85) A ctags/main/entry_p.h (68) A ctags/main/entry_private.c (37) M ctags/main/error.c (41) M ctags/main/field.c (952) M ctags/main/field.h (47) M ctags/main/flags.c (107) R ctags/main/flags_p.h (16) M ctags/main/fmt.c (57) R ctags/main/fmt_p.h (0) M ctags/main/general.h (13) A ctags/main/gvars.h (29) A ctags/main/interactive_p.h (29) M ctags/main/keyword.c (18) M ctags/main/keyword.h (9) A ctags/main/keyword_p.h (26) M ctags/main/kind.c (536) M ctags/main/kind.h (78) M ctags/main/lcpp.c (72) M ctags/main/lcpp.h (4) M ctags/main/lregex.c (2230) A ctags/main/lregex.h (47) A ctags/main/lregex_p.h (76) D ctags/main/lxcmd.c (1227) M ctags/main/lxpath.c (12) A ctags/main/lxpath.h (81) M ctags/main/main.c (194) M ctags/main/mbcs.h (23) M ctags/main/nestlevel.c (1) M ctags/main/nestlevel.h (1) M ctags/main/options.c (1985) M ctags/main/options.h (167) A ctags/main/options_p.h (183) D ctags/main/output-ctags.c (59) D ctags/main/output.h (50) A ctags/main/param.c (57) A ctags/main/param.h (38) M ctags/main/parse.c (2988) M ctags/main/parse.h (246) A ctags/main/parse_p.h (154) M ctags/main/parsers.h (3) M ctags/main/promise.c (223) M ctags/main/promise.h (12) A ctags/main/promise_p.h (24) M ctags/main/ptag.c (84) R ctags/main/ptag_p.h (9) M ctags/main/read.c (622) M ctags/main/read.h (42) M ctags/main/repoinfo.h (2) M ctags/main/routines.c (129) M ctags/main/routines.h (75) A ctags/main/routines_p.h (107) M ctags/main/selectors.c (190) M ctags/main/selectors.h (14) M ctags/main/sort.c (94) M ctags/main/strlist.c (106) M ctags/main/strlist.h (2) A ctags/main/subparser.h (81) M ctags/main/trace.h (101) M ctags/main/types.h (30) A ctags/main/writer-ctags.c (292) A ctags/main/writer-etags.c (133) A ctags/main/writer-json.c (248) A ctags/main/writer-xref.c (72) A ctags/main/writer.c (112) A ctags/main/writer_p.h (81) M ctags/main/xtag.c (350) M ctags/main/xtag.h (43) M ctags/parsers/c.c (4) M ctags/parsers/cobol.c (2) M ctags/parsers/erlang.c (1) M ctags/parsers/go.c (3) M ctags/parsers/make.c (1) M ctags/parsers/objc.c (3) M ctags/parsers/pascal.c (2) M ctags/parsers/perl.c (1) M ctags/parsers/python.c (1) M ctags/parsers/r.c (1) M ctags/parsers/ruby.c (2) M ctags/parsers/rust.c (4) M ctags/parsers/sql.c (2) M src/tagmanager/tm_parser.c (2) M tests/ctags/Makefile.am (5) M tests/ctags/Package.pm.tags (3) M tests/ctags/bug1938565.sql.tags (2) M tests/ctags/random.sql.tags (7) M tests/ctags/refcurs.sql.tags (2) A tests/ctags/simple.as (44) A tests/ctags/simple.as.tags (20)
-- Patch Links --
https://github.com/geany/geany/pull/2132.patch https://github.com/geany/geany/pull/2132.diff
So yeah, Windows build fails as expected.
@techee On my Windows there's a `regex.h`-compatible header provided by [libsystre](https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libsystre).
I'd really like if this could get merged soon because I don't want to get again to the state where I have to merge multi-year diffs from uctags. My proposal is that I'd prepare a patch at the beginning of every Geany release cycle which syncs it with uctags
Pretty close, Geany is currently in string freeze for a release, so _maaaaybe_ it can get committed immediately after.
@techee pushed 6 commits.
bc1dd6f361bb628efed452297c6ac0f3ad297d71 Check also regex parser kind mappings 3de0df0872e237d955e291a27db913e650e8b8a9 Keep the first parser in ctags CTagsSelfTestParser and remap Geany languages b22b17e1aa22dbf2f3a11a84304a024f611961a2 Make Geany informed about failed reparses "the right way" aeef700767660a75da5cd456c4adbee03b5da300 Move ctags-api.c/h into tagmanager and rename it to tm_ctags.c/h 266283c9a1aa3aa22bc384e2c61acb61135926fe Eliminate intermediate data types and callbacks 7741ef0c12bd6f9ae75ff5f2db1ab44bb327bcd2 GLibify and Geanify tm_ctags.c/h
@techee pushed 3 commits.
97cf266debfc7860212770b8116275d1592ca7e4 Remove pcoproc.c/h which isn't in the upstream version any more 77f83326cd144ed0f615e04522113a11d27e0fa6 Enable XTAG_REFERENCE_TAGS cbb6f78c63faa7dde53b10139074a8eb7ccbe067 Use g_logv() for logging ctags errors
I've just fetched and tested (at my humble level) this huge work right now. I opened randomly some cython, COBOL, LaTeX, vala, C files: no problem. About COBOL as this is one of these regex-parsed languages, I made sure that I ran the regex-one by editing the source file, making some changes to a regex and ensure that it had some effects. Looks all good at first sight then :)
@johndescs Thanks. I'll eventually remove the Cobol and Actionscript parsers as they are now replaced by much better Colomban's hand-written parsers but for the purpose of this pull request they are useful to test regex parsing because they are the only regex parsers we have.
@techee pushed 4 commits.
a63f7ac9435186a6f38422d74ab4b3554b751023 Sync against ctags version which supports most of Geany functionality 7559ed2a9eda4a27e26297c64cd24599ac568ba6 Rename current_source_file to just source_file 4a8ea44436969c1d32b557686934a8ec9dd7eae4 Whitespace 75c8c6c829f481d0b75c5d70eb1f51b3334234c9 Move lcpp.c/h inside parsers dir
I've updated the patch to use the latest ctags which already contains most of the functionality we need. There are still 2 things needed upstream:
https://github.com/universal-ctags/ctags/pull/2100 https://github.com/universal-ctags/ctags/pull/2087
After this the only change of the main directory against uctags will be the patch which changes how anon tags are named (instead of Anon<hash> we use Anon<number>). I'll then prepare a patch file which we'll just need to apply every time we copy ctags main directory to Geany.
Please consider git-subtree instead of maintaining patch files
@kugel- How well would it work, when: 1. The `parsers` directory is VERY different from upstream and the diff would be giant. 2. We only use the `main` and `parsers` directory from https://github.com/universal-ctags/ctags - we don't use anything else. Now of course we could add all the rest as well, including the tons of unit tests, docs, etc. but I'm not sure it's a good idea.
Now I have no experience with git subtrees so maybe this is solvable somehow. I'm just afraid we'd get huge amount of stuff we don't care about and having to deal with all the diffs and merge conflicts inside `parsers` whenever something changes upstream would make our life much harder.
The problem doesn't need sexy things like git subtrees, we are not developing UCtags. What it needs is a script that copies the relevant files from a clone of UCtags to a Geany clone so not just superman @techee but an ordinary human can update it without making mistakes.
The problem doesn't need sexy things like git subtrees, we are not developing UCtags. What it needs is a script that copies the relevant files from a clone of UCtags to a Geany clone so not just superman @techee but an ordinary human can update it without making mistakes.
After this pull request the update of ctags main will look like: 1. rm geany/ctags/main/* 2. cp ctags/main/*.c ctags/main/*.h geany/ctags/main 3. Apply the 6-line anonymous tag patch (without which everything should compile just fine) 4. Update Makefile.am if files have been removed or added (5. Possibly update parsers if they were affected by some change in main)
The script needs to include updating the parsers to their latest version, to be blunt nobody cares about main, its just overhead to make the parsers work. So the script should copy the parsers that are taken unchanged from upstream too. If changes to main mean any local parsers (c.c, any others left?) need updating thats a different issue, but copying matching parsers from upstream at the same time as main should ensure they work.
I'm afraid there are tons of parsers that aren't synced yet apart from c.c. I'd suggest giving those parsers the `geany_` prefix (e.g. `geany_c.c`) so it's clear already from the file name about which parsers we don't have to care about and where we have some work to do syncing them with the upstream versions. (And yes, in addition to that the script copying the non-`geany_` parsers is a good idea.)
@techee pushed 5 commits.
1c4dcae9a6fa71eab1b5471e95c89168a0fb5b4d Use g_return_if_fail() and remove unneeded includes 5c35fa79575a80498b18500c2d0c8e1904418a91 Actually move the lcpp files themselves 361c058b3f727a3d4cda9e4908b588f98f151f83 Make sure we compile all sources from upstream main 0182f7d1f0d254388fa9746c98dcb9941f6d488b Add a patch file containing the only change we need against uctags 2587ccf8afbe4fea2f42e96c444c03ea0efab4d7 We can use WRITER_CUSTOM now
Agree that naming the geany parsers obviously will help avoid human errors, like simply adding them to the script and having them overwritten.
Agree that naming the geany parsers obviously will help avoid human errors, like simply adding them to the script and having them overwritten.
For updating to new ctags version the script will definitely be better. But in the long term we should try to eliminate all the differences in our and uctags parsers and then it's useful to easily see where we have some work to do.
@techee pushed 2 commits.
170b388ec857983c3bba0489633a1c68e13a5227 Inject our parser list to ctags d68731da6af74befe54a4427680426ff2542afd0 Remove dirent.h check which is not needed because of upstream changes
@b4n I'm done, phew! It's your turn :-)
The current state is this: if you delete geany/ctags/main, replace it with upstream-ctags/main and apply the 6-line patch (which I might eliminate in the future, it just requires some help on the uctags side and some more work on our side), you are done. This is the very last manual ctags/main sync so you'd better enjoy reviewing it - such an opportunity won't happen in the future ;-)
In any case, it doesn't make sense to review the patches as they are in this pull request - most of it is just how I tried to reduce the number of diffs against uctags and also originally I didn't even dream about having a full sync so there are some patches trying to simplify future manual syncs which are pointless now.
I think to review this it's best to first look at the corresponding upstream changes - it's these pull requests:
https://github.com/universal-ctags/ctags/pull/2088 https://github.com/universal-ctags/ctags/pull/2102
Then, the majority of Geany changes is inside src/tagmanager/tm_ctags.c and this file should be reviewed as a whole. It however resembles the mini-geany.c test mostly, it just does our specific things with the collected tags. To avoid extra callbacks, I moved tag creation functions from tm_source_file_c to this file in
https://github.com/geany/geany/pull/2132/commits/266283c9a1aa3aa22bc384e2c61...
Other patches from this pull request worth looking at are:
https://github.com/geany/geany/pull/2132/commits/2413f2e170bdd6b708cad715de0... https://github.com/geany/geany/pull/2132/commits/f6139d3b26e3bcfe847f94a9546... https://github.com/geany/geany/pull/2132/commits/75c8c6c829f481d0b75c5d70eb1... (and its bugfix https://github.com/geany/geany/pull/2132/commits/5c35fa79575a80498b18500c2d0...) https://github.com/geany/geany/pull/2132/commits/0182f7d1f0d254388fa9746c98d... https://github.com/geany/geany/pull/2132/commits/170b388ec857983c3bba0489633...
The rest is just intermediate garbage.
I'd suggest that you have a look at what I described above, play with the ActionScript and Cobol regex parsers to see they work and if everything is OK, I'll rebase this pull request this way:
1. I remove the ActionScript and Cobol regex parsers and the related code 2. I'll make the ctags changes a single commit - basically "sync to upstream ctags version" where I copy-over the ctags main and apply the patch 3. I'll make a single commit containing all the Geany changes (something like "make Geany compile with the upstream ctags") so it will be easier to see what changes were made on the Geany side
Does it sound OK to you?
@b4n Oh yeah, and one more thing. The build on Windows where regex is missing and it will have to probably be copied from uctags and integrated to our build system - I'll leave this one to you so you don't feel there's no work left for you ;-).
Does travis work by the way? It seems I stopped getting builds for the last commits.
Maybe because of the conflicts Travis doesn't know how to merge the PR to test it.
Since @b4n's real Cobol is already in Geany you can't merge a regex version as well, similarly as the actionscript parser is already committed as part of flex.c you can't merge a regex version of it either.
Since @b4n's real Cobol is already in Geany you can't merge a regex version as well, similarly as the actionscript parser is already committed as part of flex.c you can't merge a regex version of it either.
Hmm, didn't I say something like this myself? ;-)
I'll rebase this pull request this way:
- I remove the ActionScript and Cobol regex parsers and the related code
Maybe because of the conflicts Travis doesn't know how to merge the PR to test it.
Does travis merge pull requests? I thought the branches are tested as they are.
OK, from https://docs.travis-ci.com/user/pull-requests/ travis really merges the branch:
Travis CI builds a pull request when it is first opened, and whenever commits are added to the pull request. Rather than build the commits that have been pushed to the branch the pull request is from, we build the merge between the source branch and the upstream branch.
I assumed it's the branch which is tested. So everything is clear then.
codebrainz commented on this pull request.
@@ -44,7 +44,6 @@ AC_CHECK_HEADERS([fcntl.h glob.h stdlib.h sys/time.h errno.h limits.h])
# Checks for dependencies needed by ctags AC_CHECK_HEADERS([fnmatch.h direct.h io.h sys/dir.h]) AC_DEFINE([HAVE_STDBOOL_H], [1], [whether or not to use <stdbool.h>.]) -AC_CHECK_HEADERS(dirent.h,have_dirent_h=yes)
I only looked at this one teeny part, but `dirent.h` is still included in `main.c` in Geany and upstream. Is the intention to just permanently guard out it's inclusion via `HAVE_DIRENT_H` never being defined? Feel free to ignore me, it just looked funny.
techee commented on this pull request.
@@ -44,7 +44,6 @@ AC_CHECK_HEADERS([fcntl.h glob.h stdlib.h sys/time.h errno.h limits.h])
# Checks for dependencies needed by ctags AC_CHECK_HEADERS([fnmatch.h direct.h io.h sys/dir.h]) AC_DEFINE([HAVE_STDBOOL_H], [1], [whether or not to use <stdbool.h>.]) -AC_CHECK_HEADERS(dirent.h,have_dirent_h=yes)
It wasn't there before - I added it in https://github.com/geany/geany/pull/2132/commits/361c058b3f727a3d4cda9e4908b... and then because of this https://github.com/universal-ctags/ctags/pull/2100 it could be dropped again.
@kugel- How well would it work, when:
1. The `parsers` directory is VERY different from upstream and the diff would be giant. 2. We only use the `main` and `parsers` directory from https://github.com/universal-ctags/ctags - we don't use anything else. Now of course we could add all the rest as well, including the tons of unit tests, docs, etc. but I'm not sure it's a good idea.Now I have no experience with git subtrees so maybe this is solvable somehow. I'm just afraid we'd get huge amount of stuff we don't care about and having to deal with all the diffs and merge conflicts inside `parsers` whenever something changes upstream would make our life much harder.
I thought we are trending towards using upstream as-is, with only small changes needed (including new files).
Well, with git-subtree, syncing to upstream is done by a conventional merge. That means: - Files where we don't make changes always merge fine (for dirs we don't use). - Our changes and upstream changes are merged by git's methods - deletions/renamings can cause tree conflicts which are messy to deal with
If you say that our copy is wildly different and continues to be so then git-subtree may not be perfect. Otherwise we are enabled to sync via a single "git subtree pull <url> <tag>" command and have git handle the merging. Plus we wouldn't need to maintain diffs separately but simply make commits directly to the code.
I thought we are trending towards using upstream as-is, with only small changes needed (including new files).
Yes, we are, but currently it's only the `ctags/main` directory (there's the 6-line diff but I want to eliminate it as well - will do it in a separate pull request once this pull request is merged). But for `ctags/parsers` it's more like ~10000 LOC diff and for many parsers it will be a bi-directional process - we have some code that should be added upstream and some upstream code should be added to our parsers. I think in the current situation git subtree wouldn't be very practical.
@kugel- you could make a separate issue with a proof of concept with something simpler like [Scintilla](https://github.com/mirror/scintilla). This seems like a good goal ultimately, even if ctags fork isn't ready yet.
@b4n commented on this pull request.
OK, so I diffed ctags/main against https://github.com/universal-ctags/ctags/commit/3fdf28bcd3aac31ee226f588f7d2... (`git diff --no-index ../geany/ctags/main main`) which seems to be the merged version matching this PR (the comment in one of the commits refer to a uctags commit that doesn't seem to exist?), and the diff is indeed almost non-existent! :tada: I didn't check the actual uctags changes, because it would be better done following uctags history anyway, and I'm mostly confident it should be fine.
I know you do know this already, but the change here is enabling *all* kinds, which notably includes prototypes for SQL and Perl, which weren't there before. I don't think it should be a problem, but it's worth noting. It actually includes all of those, although most don't actually change behavior: * C, D: protoypes, external variables (actually, those tags are generated even if disabled). * C#, Vala: local variables (doesn't actually apply to Geany as it's mapped to `tm_tag_undef_t`, and those tags were already generated anyway even if disabled). * Fortran: local variables (doesn't actually apply to Geany as it's mapped to `tm_tag_undef_t`). * Perl: subroutine declarations. * PHP: local variables (doesn't actually apply to Geany as it's mapped to `tm_tag_undef_t`). * SQL: protoypes, local variables, records (doesn't actually apply to local variables and records in Geany as they are mapped to `tm_tag_undef_t`).
One thing that doesn't seem to affect us (I'm not really sure of the actual impact though) but could have a problematic effect is the switch to unconditional use of the `F` kind for file tags. ObjectiveC, Ruby, Rust and SQL all use this letter for their own tags, which could be a source of conflict. I would think it'd be safer to switch to the updated upstream letters: ```diff diff --git a/ctags/parsers/objc.c b/ctags/parsers/objc.c index 1558229ce..83966b8fe 100644 --- a/ctags/parsers/objc.c +++ b/ctags/parsers/objc.c @@ -46,7 +46,7 @@ static kindDefinition ObjcKinds[] = { {true, 'm', "method", "Object's method"}, {true, 'c', "class", "Class' method"}, {true, 'v', "var", "Global variable"}, - {true, 'F', "field", "Object field"}, + {true, 'E', "field", "Object field"}, {true, 'f', "function", "A function"}, {true, 'p', "property", "A property"}, {true, 't', "typedef", "A type alias"}, diff --git a/ctags/parsers/ruby.c b/ctags/parsers/ruby.c index d269709da..c6ab3e44d 100644 --- a/ctags/parsers/ruby.c +++ b/ctags/parsers/ruby.c @@ -39,7 +39,7 @@ static kindDefinition RubyKinds [] = { { true, 'c', "class", "classes" }, { true, 'f', "method", "methods" }, { true, 'm', "module", "modules" }, - { true, 'F', "singletonMethod", "singleton methods" }, + { true, 'S', "singletonMethod", "singleton methods" }, #if 0 /* Following two kinds are reserved. */ { true, 'd', "describe", "describes and contexts for Rspec" }, diff --git a/ctags/parsers/rust.c b/ctags/parsers/rust.c index 017afefcc..70c31d139 100644 --- a/ctags/parsers/rust.c +++ b/ctags/parsers/rust.c @@ -58,7 +58,7 @@ static kindDefinition rustKinds[] = { {true, 'M', "macro", "Macro Definition"}, {true, 'm', "field", "A struct field"}, {true, 'e', "enumerator", "An enum variant"}, - {true, 'F', "method", "A method"}, + {true, 'P', "method", "A method"}, };
typedef enum { diff --git a/ctags/parsers/sql.c b/ctags/parsers/sql.c index eb4e3e530..d7ff87689 100644 --- a/ctags/parsers/sql.c +++ b/ctags/parsers/sql.c @@ -204,7 +204,7 @@ static kindDefinition SqlKinds [] = { { true, 'c', "cursor", "cursors" }, { false, 'd', "prototype", "prototypes" }, { true, 'f', "function", "functions" }, - { true, 'F', "field", "record fields" }, + { true, 'E', "field", "record fields" }, { false, 'l', "local", "local variables" }, { true, 'L', "label", "block label" }, { true, 'P', "package", "packages" }, diff --git a/src/tagmanager/tm_parser.c b/src/tagmanager/tm_parser.c index 52468c741..9e9130b4d 100644 --- a/src/tagmanager/tm_parser.c +++ b/src/tagmanager/tm_parser.c @@ -142,7 +142,7 @@ static TMParserMapEntry map_SQL[] = { {'c', tm_tag_undef_t}, {'d', tm_tag_prototype_t}, {'f', tm_tag_function_t}, - {'F', tm_tag_field_t}, + {'E', tm_tag_field_t}, {'l', tm_tag_undef_t}, {'L', tm_tag_undef_t}, {'P', tm_tag_package_t}, @@ -192,7 +192,7 @@ static TMParserMapEntry map_RUBY[] = { {'c', tm_tag_class_t}, {'f', tm_tag_method_t}, {'m', tm_tag_namespace_t}, - {'F', tm_tag_member_t}, + {'S', tm_tag_member_t}, };
static TMParserMapEntry map_TCL[] = { @@ -437,7 +437,7 @@ static TMParserMapEntry map_OBJC[] = { {'m', tm_tag_method_t}, {'c', tm_tag_class_t}, {'v', tm_tag_variable_t}, - {'F', tm_tag_field_t}, + {'E', tm_tag_field_t}, {'f', tm_tag_function_t}, {'p', tm_tag_undef_t}, {'t', tm_tag_typedef_t}, @@ -475,7 +475,7 @@ static TMParserMapEntry map_RUST[] = { {'M', tm_tag_macro_t}, {'m', tm_tag_field_t}, {'e', tm_tag_enumerator_t}, - {'F', tm_tag_method_t}, + {'P', tm_tag_method_t}, };
static TMParserMapEntry map_GO[] = { ```
Apart from that, looks great! It also seems pretty easy to merge into master, with the exception of *simple.as* for which I'm not sure of the results.
I'm also not quite sure for the Windows part, but I'm sure @eht16 will figure this out :wink: One thing I *think* I noticed is that uctags' gnu_regex wasn't glibc's current version at the time, but I didnt re-check now. Also, I guess if it's availble from a third party in MSYS as @codebrainz suggested, maybe we can just make use of that instead of maintaining a copy on our side. Or would that cause issues in nightly builds or something? @eht16
@techee are you willing to follow up as you planned in https://github.com/geany/geany/pull/2132#issuecomment-494785616, or did the 1.5year gap killed that bird? (I can't be sorry enough, although I just couldn't find enough time to do it properly -- and even now, I'm partially trusting you and uctags on this :slightly_smiling_face: ) I'd understand either way, but I'd love to get that in pretty early in this cycle so we could actually get this in and have some field testing as well, so I'd love to know.
I know you do know this already, but the change here is enabling all kinds, which notably includes prototypes for SQL and Perl, which weren't there before.
Yeah, basically I think it's best to enable all kinds and then disable those we are not interested in using `tm_tag_undef_t`. We could do this with with the C, D, SQL and Perl prototypes too if we wanted, I just left `tm_parser.c` the way it was before.
@techee are you willing to follow up as you planned in #2132 (comment), or did the 1.5year gap killed that bird? (I can't be sorry enough, although I just couldn't find enough time to do it properly -- and even now, I'm partially trusting you and uctags on this 🙂 )
Sure, let's do this finally! Just give me 1 year to update the patches :-).
Now seriously, is it OK if I rebase the patches as I suggested? I'll also add the diff from you and make them on top of the current master.
Sure, let's do this finally! Just give me 1 year to update the patches :-).
Fair enough :smile:
Now seriously, is it OK if I rebase the patches as I suggested? I'll also add the diff from you and make them on top of the current master.
Yeah, that sounds great. If there's anything you can split in the Geany side of it don't hesitate, but I guess it's all pretty much one step of making it fit.
I'm closing this pull request in favor of #2666.
Closed #2132.
github-comments@lists.geany.org