[Github-comments] [geany/geany] The very last manual ctags/main sync (I promise) (#2132)

Colomban Wendling notifications at xxxxx
Sun Nov 15 22:47:11 UTC 2020


@b4n commented on this pull request.

OK, so I diffed ctags/main against https://github.com/universal-ctags/ctags/commit/3fdf28bcd3aac31ee226f588f7d2ce32659d2637 (`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.



-- 
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/pull/2132#pullrequestreview-530844106
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20201115/d49c69e2/attachment-0001.htm>


More information about the Github-comments mailing list