[Github-comments] [geany/geany] New tagmanager query module (#1187)

[Thomas Martitz]

Am 29.08.2016 um 17:52 schrieb Jiří Techet:
>     I don't see why TM couldn't be improved to support other, AST-based
>     parsers. Sure TM is lacking now but we cna fix that. I don't think
>     it's too much work.
>
> Good, modify tag array merging
>
> https://github.com/geany/geany/blob/master/src/tagmanager/tm_tag.c#L375
>
> to work on trees that is similarly fast and let's talk then ;-).


The plugin probably would provide a list, which it generated internally 
from whatever representation.


>
>     But coming back to this PR. I don't think the proposed query API is
>     affected by the above ideas. It'll always be used to return a list
>     of tags. If the TMTag structure changes for new features or are
>     subtrees instead of plain tags is a different story.
>
> As I think TM should be used for ctags-like tags, lists should be fine.
> (They would be insufficient if you needed some AST information, e.g. for
> code completion.)


Then TM should be improved to hold sufficient information. auto 
completion leaves a lot to be desired even for ctags based tags so 
there's definitely work to do on the TM side.

I wonder what makes you guys think this list vs tree(AST) makes things 
fundamentally unworkable? It's a complete non-issue to me. It's just a 
representation that can be converted as needed.

Anyway, as @elextr also said, I think that even if TM would use a 
completely different internal representation (such as a tree), the query 
results would most likely still be a list. Similarly to DB queries, 
which also return flat tables. So the list vs tree discussion becomes 
orthogonal to this PR.


-- 
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/1187#issuecomment-243358385
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160830/b4b29b30/attachment.html>