[Geany-Devel] [FT-plugins] Proposed "Features"
kugel at xxxxx
Tue Aug 30 21:29:35 UTC 2016
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
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
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.
More information about the Devel