[Geany-Devel] [FT-plugins] Proposed "Features"

[Thomas Martitz]

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.