@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
