You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These will be implemented as a bool attribute in a role structure:
diff --git a/main/kind.h b/main/kind.h
index 5a9b243a6..4d063621c 100644
--- a/main/kind.h
+++ b/main/kind.h
@@ -24,7 +24,7 @@ struct sRoleDefinition {
bool enabled;
char* name; /* role name */
char* description; /* displayed in --help output */
-
+ bool depedencyRole; /* Better name? */
int id;
};
We have to add a column for "dependency" to the output of ctags --list-roles.
> M-. becomes slower maybe because readtags reports too many tags.
The problem is until now, Citre assumes tags files don't contain "reference tags" in the general sense. u-ctags only emits reference tags that point to external modules/files (let's call them dependency references for now). They are useful and aren't too many, so Citre doesn't filter them out when finding definitions.
But after this PR, uctags emits reference tags pointing to general entities (let's call them general reference for now). Citre should exclude them when finding definitions, and include them when finding references. We could do this in 2 ways:
Only exclude general reference tags. This has the advantage of keeping M-. behavior of Citre unchanged. We could do this by excluding tags that have "unknown" kind and "ref" role, but if in the future, they are tagged with the correct kind (variable, function, etc.), this technique won't work anymore.
Exclude all reference tags. In this way, M-. on a module/file name won't list its references. You have to use M-? for that.
Personally I feel the second way is better.
The question is whether M-. of citre users becomes slower or not if I merge this branch today.
It won't become slower as you already pointed out.
P.S. Actually I think tagsfile is not the best format for references. If we create a tagline for every symbol in a codebase, the tagsfile could become larger than the codebase itself. A binary database (like GNU global does) could save much space. But this is only my own thoughts. It may be unrealistic to make necessary changes to uctags for solving this problem.
These will be implemented as a bool attribute in a role structure:
We have to add a column for "dependency" to the output of
ctags --list-roles
.The problem is until now, Citre assumes tags files don't contain "reference tags" in the general sense. u-ctags only emits reference tags that point to external modules/files (let's call them dependency references for now). They are useful and aren't too many, so Citre doesn't filter them out when finding definitions.
But after this PR, uctags emits reference tags pointing to general entities (let's call them general reference for now). Citre should exclude them when finding definitions, and include them when finding references. We could do this in 2 ways:
Personally I feel the second way is better.
It won't become slower as you already pointed out.
P.S. Actually I think tagsfile is not the best format for references. If we create a tagline for every symbol in a codebase, the tagsfile could become larger than the codebase itself. A binary database (like GNU global does) could save much space. But this is only my own thoughts. It may be unrealistic to make necessary changes to uctags for solving this problem.
Originally posted by @AmaiKinono in #3535 (comment)
The text was updated successfully, but these errors were encountered: