Am 29.08.2016 um 17:05 schrieb Jiří Techet:
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.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
https://github.com/geany/geany/pull/1187
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.
1) trees can be stored in flat list simply by storing the tree path in each element (like GtkTreeModel). This is not crazy or complex. It's even readily available in the scope string. 2) I don't see why the AST needs to be recoverable from a TM tag list. You only need to map from X to TM, so losing information is OK as long as it's sufficient for the function of current features/use cases (for future features TM tag list may or may not needed to be enhanced).
Please show me how the proposed tag-related features require advanced tag management that isn't possible with TM if tags would be supplemented or completely provided by a plugin.
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.
Right, this is basically what I'm looking at. I can't see how we need anything more at this point. And yes, I do care that Geany itself and plugins (including mine) have a unified interface to access all tags, regardless of who provides them. Matthews proposal prohibits this.
There is also another aspect about the proposal that worries me: a plugin shall provide N features for M languages. And X plugins might be compete (not even considering the desire that plugins can build upon each other). This means (slightly exaggerated) that N*M*X possibilities have to be managed by Geany's conflict resolution. I don't want to implement that. It seems much simpler to me to collect tags from plugins, merge them (maybe throw out duplicates) and pass them to the actual feature code all within Geany.
What worries me is that we jumped from mere brainstorming to a relatively concrete proposal, without evaluating requirements or any other research. Or was this evaluation just invisible to me?
Best regards.