Am 30.08.2016 um 21:10 schrieb Jiří Techet:
Geany would then merge the tags, perhaps giving the plugin ones more weight, and store it in TM. I think you underestimate how many tags we're talking here. The example libclang ft-plugin would have to re-walk the entire AST (which is absolutely massive, particularly for C++), convert it to TM tag structures, and then Geany/TM would have to perform some merging logic, would would be more complicated than now if it was to support C++ properly, every single re-parse. My intuition tells me that just won't be fast enough, Clang already jumps through hoops and uses tricks to just build its own AST in-time.I think it would be a disaster performance-wise. The number of AST nodes can be easily 100x more than the amount of tags we have from ctags (we get a single tag for a function now and AST will contain complete tree for the function body) so just this might cost 100x more. In addition all the necessary copies to TM internal representation, having to maintain the tree structure (in TM we use GPtrArrays for everything which are very efficient and during tag merge we try to eliminate even pointer dereferences because those start getting expensive when managing many tags) etc.
Let's not outright reject possible solutions based on performance assumptions and guestimations. Performance can be evaluated on an actual implementation. Until then it's simply an invalid argument for this discussion. But FWIW, I don't think performance is the driving aspect.
What's needed from the AST is tags (as you and I mentioned elsewhere, AST is the complete code representation, so much more than what's required currently). Those can be extracted in one pass. I don't see that tags need to be converted back to the original AST.
For any successful plugin operation, the AST has to be generated (and probably re-generated regularly) and traversed at least once. Creating tags in a traversal that's happening done anyway probably isn't even going to add much overhead, if any.
As you say, we use a GPtrArray of tags because it's very efficient for sorting and merging. I think any ft-plugin will also have to sort (at least) for showing auto-completion and symbols tree - if it shows them itself. So it may even have to create such array/lists that TM uses anyway (you can't sort AST directly). So it might as well pass them to TM for sorting.
And even if we did this, I don't know how we could handle ASTs of different languages in a generic way because these will differ significantly.
One more time, seems I wasn't clear enough yet: I'm *not* suggesting that we create generic code inside Geany that handles any kind of AST. What I suggest is that plugins that use AST internally (or not) pass tag-like information to Geany, extracted and flattened from its internal AST (or whatever it uses). Then Geany and other plugins can use that information for their own purposes.
Anyway, if needed we can always add more elements to the TMTag structure so plugins can add some more information.
Yes. I do want to be able to implement new tag-related features in Geany or other plugins. So if an ft-plugin improves tags over Geany's builtin abilities, then these should become generally available.
Otherwise we get into a situation where core features of Geany become exclusive to individual plugins and cannot be improved upon again (get stuck with a unmaintained plugin that isn't updated to newer Geany features, anyone?).
Considering the poor quality and orphaned status of some G-P plugins, I wouldn't want to give individual plugins exclusive access to otherwise appreciated features which are mostly working in Geany core as of today. I'd rather not use ft-plugins at all if they provoke such a situation.
Best regards.