<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The solution I have in mind simply allows plugins to pass tags to Geany which they parsed with more advanced code. The tags itself would advanced too, to allow for the improvements current TM+ctags can't offer. Symbol tree, calltips, autocompletion, jump-to-decl can all be improved based on the advanced tags.<br></blockquote><div><br></div><div>I'm personally very happy that Matthew decided to go the way he proposed instead of doing what you propose. As I said in one of the posts here</div><div><br></div><div><a href="https://github.com/geany/geany/pull/1187">https://github.com/geany/geany/pull/1187</a><br></div><div><br></div><div>it's not a matter of how "advanced" the tags are but that the tags are represented in a completely different way - tree vs list. There's info in the tree that cannot be stored in the list and similarly ctags list cannot be converted to AST. You can start doing some crazy things like serializing AST to a list and then deserializing it to a tree or having parallel AST-TM and list-TM but things are complicated enough in TM already and merging ASTs during source file updates would be really complicated. Also performance would suffer because operations on GPtrArrays are really fast as they don't require pointer dereferencing. In addition I think each library will have its own partially incompatible AST representation and different info will be needed e.g. for autocompletion and it will be really hard to find something generic enough.</div><div><br></div><div>So big +1 for Matthew's approach from me. What might be good though is filling the "simple" TMTags with "advanced" libclang or any other tags into the existing TM. Some info will be lost on the way but this info will be sufficient for some things like the symbol tree or your plugin.</div><div><br></div><div>Jiri</div></div></div></div>