[Github-comments] [geany/geany] Use cxx parser from uctags (PR #3032)
Jiří Techet
notifications at xxxxx
Wed Dec 1 11:05:51 UTC 2021
@masatake After thinking about it for a while, is it actually a good idea to distinguish between imports and package definitions using a role in go (and possibly some other languages)? The way I understand semantics of roles is that they further distinguish the nature of a single kind but if this extra information is ignored, nothing bad happens. For instance in Python I think the following is alright because it just distinguishes different types of imports
```
/* Roles related to `import'
* ==========================
* import X X = (kind:module, role:imported)
*
* import X as Y X = (kind:module, role:indirectlyImported),
* Y = (kind:namespace, nameref:module:X)
* ------------------------------------------------
* Don't confuse the kind of Y with namespace role of module kind.
*
* from X import * X = (kind:module, role:namespace)
*
* from X import Y X = (kind:module, role:namespace),
* Y = (kind:unknown, role:imported, scope:module:X)
*
* from X import Y as Z X = (kind:module, role:namespace),
* Y = (kind:unknown, role:indirectlyImported, scope:module:X)
* Z = (kind:unknown, nameref:unknown:Y) */
```
But package definitions and imports of other packages are two fundamentally different things and IMO there should rather be two different kinds in go for these.
Note: Take the above as a note of someone who is lazy to do the extra work in Geany and possibly just tries to figure out how to delegate some work to others :-). What I wrote above make sense in my (very biased) brain but whatever is implemented should primarily be a good thing for ctags.
--
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/3032#issuecomment-983530028
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20211201/27975c2a/attachment.htm>
More information about the Github-comments
mailing list