universal-ctags
main: introduce type: field
(After discussion the field name introduced this pull request is changed from varType" to type:) HELP MESSAGE is not filled yet.
varType: field is introduced in this commit. The value for the field is passed via typeRef[1] of tagEntryInfo from a parser to the main part.
To emit the string pointed by typeRef[1] as varType: field, typeRef[0] must be NULL and the field is enabled with --field=+T. Here 'T' is the letter for varType: field.
Signed-off-by: Masatake YAMATO [email protected]
Nice, this could work well I think both for Geany (which can detect varType by typeRef[0] == NULL) and ctags too. As for the ??? I'd say something like "Variable type or function return type".
Maybe it would be also worth thinking whether "varType" is the right name (it isn't used only for variables but for functions too). Maybe it could be just named "type" as it isn't used only for variables but also for function return values.
@masatake Just noticed your suggestion for the ??? in the other issue comment - it sounds fine too.
I really like "type:". Is it acceptable in Geany side?
It doesn't really matter because Geany reads sTagEntryInfo directly and not the tag files. At the moment we have varType in sTagEntryInfo and there's no typeRef but it will be fairly easy to introduce typeRef and use it instead of varType.
There is one quirk with the C++ parser: backward compatibility. "typeRef" was used in exuberant ctags for the types associated to some typedefs (the ones that were extracted: only very specific cases). So it's unclear what to use when +T will be enabled. Everything rendered as "type" instead of "typeRef"? Only variable and function return types as "type" and typedef types as "typeRef"? Other ideas?
There is one quirk with the C++ parser: backward compatibility. "typeRef" was used in exuberant ctags for the types associated to some typedefs (the ones that were extracted: only very specific cases). So it's unclear what to use when +T will be enabled. Everything rendered as "type" instead of "typeRef"? Only variable and function return types as "type" and typedef types as "typeRef"? Other ideas?
That's a good question.
I find the semantics of which types are used for typeRef[0] not very well defined - it's used for some selected C types but it's for instance quite unclear what should be done in other languages with possibly different keywords. On the other hand, C is quite specific that it has separate struct namespaces so you have to write the keyword "struct" in front of the type even for variable declarations - I guess in most languages you'll just write the type name so there will be nothing left for typeRef[0] and the problem won't be there.
Semantically the clearest way to me seems to be having "typeRef" reserved for type definitions and "type" for the type uses (like variable/function types).
Maybe more backwards-compatible possibility is also to use NULL at the places where there was "typename" in the cxx parser - this will generate "type" for the cases where there was "typename" until now and keep the rest as it is. That means typeRef will be used also for certain variable/function types.
The third possibility is not to reuse typeRef in sTagEntryInfo for "type" and instead introduce a separate member for it and generate typeRef the same way as until now and in parallel the new "type" independently of typeRef.
(From Geany's perspective neither of the above will be a problem.)
Let's split the discussion about tags file format and implantation. About the implementation we can solve issues multiple ways as far as they don't prevent sharing code between geany anductags.
The term "typeRef" is a bit ambiguous for me. Let's use "typeref:" for typeref field of tags file format. Let's use "typeRef[]" for typeRef field of tagEntryInfo data structure.
My interest is "typeref:'.
The last comment of @techee tells the basic direction I would like to follow. The semantic of "typeref:" is not clear for me, too. So I don't want to touch/extend "typeref:" anymore. I would like to keep it just for compatibility. We should introduce new fields if we really need. In such case we should make the semantic of them clear.
I proposed the field name "type:" but I'm not sure it is good or not. @pragmaware, could you make a proposal for new field(s) and their(its) sematics which C++ parser needs. The sematics should be explained in docs/format.rst. I will make stub for the documentation.
typeRef[0] can be used for implementing new fields but it is not important here.
@masatake @pragmaware Any news on this? I'd like to start doing some ctags syncing with Geany in its current release cycle and it would be good to know how things will look in ctags. To me keeping "typeRef" just for compatibility purpose and having a separate "type" sounds good. Should I prepare a patch doing this? (I might need some help from @pragmaware with the C++ parser.)
(It seems that @pragmaware is in busy. ) I will find a temporary solution.
@masatake Sorry to bug again - any plans to address this? It's one of the things we still need resolved after https://github.com/geany/geany/pull/1263. If it's just simple addition of the "type" field while keeping typeRef for compatibility purposes, I could create a patch for this myself. But don't know if you have some other plans.