<p></p>
<p><b>@b4n</b> commented on this pull request.</p>

<p>OK, so I diffed ctags/main against <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/universal-ctags/ctags/commit/3fdf28bcd3aac31ee226f588f7d2ce32659d2637/hovercard" href="https://github.com/universal-ctags/ctags/commit/3fdf28bcd3aac31ee226f588f7d2ce32659d2637">universal-ctags/ctags@<tt>3fdf28b</tt></a> (<code>git diff --no-index ../geany/ctags/main main</code>) 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! <g-emoji class="g-emoji" alias="tada" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f389.png">🎉</g-emoji>  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.</p>
<p>I know you do know this already, but the change here is enabling <em>all</em> 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:</p>
<ul>
<li>C, D: protoypes, external variables (actually, those tags are generated even if disabled).</li>
<li>C#, Vala: local variables (doesn't actually apply to Geany as it's mapped to <code>tm_tag_undef_t</code>, and those tags were already generated anyway even if disabled).</li>
<li>Fortran: local variables (doesn't actually apply to Geany as it's mapped to <code>tm_tag_undef_t</code>).</li>
<li>Perl: subroutine declarations.</li>
<li>PHP: local variables (doesn't actually apply to Geany as it's mapped to <code>tm_tag_undef_t</code>).</li>
<li>SQL: protoypes, local variables, records (doesn't actually apply to local variables and records in Geany as they are mapped to <code>tm_tag_undef_t</code>).</li>
</ul>
<p>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 <code>F</code> 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:</p>
<div class="highlight highlight-source-diff"><pre><span class="pl-c1">diff --git a/ctags/parsers/objc.c b/ctags/parsers/objc.c</span>
index 1558229ce..83966b8fe 100644
<span class="pl-md">--- a/ctags/parsers/objc.c</span>
<span class="pl-mi1">+++ b/ctags/parsers/objc.c</span>
<span class="pl-mdr">@@ -46,7 +46,7 @@</span> static kindDefinition ObjcKinds[] = {
        {true, 'm', "method", "Object's method"},
        {true, 'c', "class", "Class' method"},
        {true, 'v', "var", "Global variable"},
<span class="pl-md"><span class="pl-md">-</span>  {true, 'F', "field", "Object field"},</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>        {true, 'E', "field", "Object field"},</span>
        {true, 'f', "function", "A function"},
        {true, 'p', "property", "A property"},
        {true, 't', "typedef", "A type alias"},
<span class="pl-c1">diff --git a/ctags/parsers/ruby.c b/ctags/parsers/ruby.c</span>
index d269709da..c6ab3e44d 100644
<span class="pl-md">--- a/ctags/parsers/ruby.c</span>
<span class="pl-mi1">+++ b/ctags/parsers/ruby.c</span>
<span class="pl-mdr">@@ -39,7 +39,7 @@</span> static kindDefinition RubyKinds [] = {
        { true, 'c', "class",  "classes" },
        { true, 'f', "method", "methods" },
        { true, 'm', "module", "modules" },
<span class="pl-md"><span class="pl-md">-</span>  { true, 'F', "singletonMethod", "singleton methods" },</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>        { true, 'S', "singletonMethod", "singleton methods" },</span>
 #if 0
        /* Following two kinds are reserved. */
        { true, 'd', "describe", "describes and contexts for Rspec" },
<span class="pl-c1">diff --git a/ctags/parsers/rust.c b/ctags/parsers/rust.c</span>
index 017afefcc..70c31d139 100644
<span class="pl-md">--- a/ctags/parsers/rust.c</span>
<span class="pl-mi1">+++ b/ctags/parsers/rust.c</span>
<span class="pl-mdr">@@ -58,7 +58,7 @@</span> static kindDefinition rustKinds[] = {
        {true, 'M', "macro", "Macro Definition"},
        {true, 'm', "field", "A struct field"},
        {true, 'e', "enumerator", "An enum variant"},
<span class="pl-md"><span class="pl-md">-</span>  {true, 'F', "method", "A method"},</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>        {true, 'P', "method", "A method"},</span>
 };
 
 typedef enum {
<span class="pl-c1">diff --git a/ctags/parsers/sql.c b/ctags/parsers/sql.c</span>
index eb4e3e530..d7ff87689 100644
<span class="pl-md">--- a/ctags/parsers/sql.c</span>
<span class="pl-mi1">+++ b/ctags/parsers/sql.c</span>
<span class="pl-mdr">@@ -204,7 +204,7 @@</span> static kindDefinition SqlKinds [] = {
        { true,  'c', "cursor",                 "cursors"                              },
        { false, 'd', "prototype",      "prototypes"                           },
        { true,  'f', "function",       "functions"                    },
<span class="pl-md"><span class="pl-md">-</span>  { true,  'F', "field",                  "record fields"                },</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>        { true,  'E', "field",                  "record fields"                },</span>
        { false, 'l', "local",                  "local variables"              },
        { true,  'L', "label",                  "block label"                          },
        { true,  'P', "package",        "packages"                     },
<span class="pl-c1">diff --git a/src/tagmanager/tm_parser.c b/src/tagmanager/tm_parser.c</span>
index 52468c741..9e9130b4d 100644
<span class="pl-md">--- a/src/tagmanager/tm_parser.c</span>
<span class="pl-mi1">+++ b/src/tagmanager/tm_parser.c</span>
<span class="pl-mdr">@@ -142,7 +142,7 @@</span> static TMParserMapEntry map_SQL[] = {
        {'c', tm_tag_undef_t},
        {'d', tm_tag_prototype_t},
        {'f', tm_tag_function_t},
<span class="pl-md"><span class="pl-md">-</span>  {'F', tm_tag_field_t},</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>        {'E', tm_tag_field_t},</span>
        {'l', tm_tag_undef_t},
        {'L', tm_tag_undef_t},
        {'P', tm_tag_package_t},
<span class="pl-mdr">@@ -192,7 +192,7 @@</span> static TMParserMapEntry map_RUBY[] = {
        {'c', tm_tag_class_t},
        {'f', tm_tag_method_t},
        {'m', tm_tag_namespace_t},
<span class="pl-md"><span class="pl-md">-</span>  {'F', tm_tag_member_t},</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>        {'S', tm_tag_member_t},</span>
 };
 
 static TMParserMapEntry map_TCL[] = {
<span class="pl-mdr">@@ -437,7 +437,7 @@</span> static TMParserMapEntry map_OBJC[] = {
        {'m', tm_tag_method_t},
        {'c', tm_tag_class_t},
        {'v', tm_tag_variable_t},
<span class="pl-md"><span class="pl-md">-</span>  {'F', tm_tag_field_t},</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>        {'E', tm_tag_field_t},</span>
        {'f', tm_tag_function_t},
        {'p', tm_tag_undef_t},
        {'t', tm_tag_typedef_t},
<span class="pl-mdr">@@ -475,7 +475,7 @@</span> static TMParserMapEntry map_RUST[] = {
        {'M', tm_tag_macro_t},
        {'m', tm_tag_field_t},
        {'e', tm_tag_enumerator_t},
<span class="pl-md"><span class="pl-md">-</span>  {'F', tm_tag_method_t},</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>        {'P', tm_tag_method_t},</span>
 };
 
 static TMParserMapEntry map_GO[] = {</pre></div>
<p>Apart from that, looks great!  It also seems pretty easy to merge into master, with the exception of <em>simple.as</em> for which I'm not sure of the results.</p>
<p>I'm also not quite sure for the Windows part, but I'm sure <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/eht16/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/eht16">@eht16</a> will figure this out <g-emoji class="g-emoji" alias="wink" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f609.png">😉</g-emoji><br>
One thing I <em>think</em> 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 <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/codebrainz/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/codebrainz">@codebrainz</a>  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? <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/eht16/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/eht16">@eht16</a></p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/techee/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/techee">@techee</a> are you willing to follow up as you planned in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="436850387" data-permission-text="Title is private" data-url="https://github.com/geany/geany/issues/2132" data-hovercard-type="pull_request" data-hovercard-url="/geany/geany/pull/2132/hovercard?comment_id=494785616&comment_type=issue_comment" href="https://github.com/geany/geany/pull/2132#issuecomment-494785616">#2132 (comment)</a>, 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 <g-emoji class="g-emoji" alias="slightly_smiling_face" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f642.png">🙂</g-emoji> )<br>
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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/pull/2132#pullrequestreview-530844106">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAIOWJ7EUNQIIGSI42HD5LDSQBK67ANCNFSM4HIG4G5Q">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AAIOWJZM4ZCRXDUHBKMWSFTSQBK67A5CNFSM4HIG4G52YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOD6SATSQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/geany/geany/pull/2132#pullrequestreview-530844106",
"url": "https://github.com/geany/geany/pull/2132#pullrequestreview-530844106",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>