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.