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

[Thomas Martitz]

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.