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

[Colomban Wendling]

Le 29/08/2016 à 10:04, Jiří Techet a écrit :
> […]
> 
> sounds good. This is much more lightweight than how #1195 and various
> other discussions sounded, I'm happy :-).

Agreed :)  I was a little afraid of seeing a proposal introducing a
gazillion GObject interfaces and GIO extension points ^^

> All the described functions look good to me in principle except the
> sidebar symbol tree one. The current code is quite complex (I was fixing
> some minor issues there and spent a lot of time thinking if it could be
> simplified but I don't think so). The problem is this: if a file is
> reparsed and you get new symbols, if you just cleared the tree and
> repopulated it with the new tags, the tree would jump to the beginning
> no matter where the scrollbar was before. So what the code does now is
> it compares the old and new tags, removes the tags that aren't present
> in the new tags array and inserts new tags which weren't present in the
> old tag array to the right position. If you have a look at the code,
> this isn't probably something you want to write in a plugin :-). So a
> plugin should provide the full list of new tags so the tree can do all
> this diffing and updating.

Agreed.  And the tree updating avoids scroll movements, flickering and
also proven significantly faster than re-building the whole tree (well,
than the previous code at least).

> Which brings me to a question - do you plan to generate TMTag(s) and
> feed them to the tag manager instead of the ctags ones? It shouldn't be
> that hard and if you do this, you could have the sidebar symbols updated
> for free.

I don't know if plugins should fill the TagManager with extra tags, but
I agree that plugins should probably use the TMTag structure to pass
Tag-like data to Geany.  For example, for symbols tree, autocompletion
suggestions and calltips: instead of providing a list of strings,
provide a list of TMTags.  As I see it, a TMTag structure contains
everything useful for the current feature set (and could be extended),
and are a fairly canonical representation of it.
A plugin could create temporary TMTags just to give to Geany, or
maintain its own list (or feed TagManager, if we wanted), but anyway
just pass the ones it want to the various APIs.

TMTags contain name, scope (useful for symbol tree and currently
calltips), type (useful for icons at least), signature, etc.  All we
need in various places.  And a plugin could leave many fields empty if
it doesn't care about them, not many fields are actually required.

Regards,
Colomban