For my GI use case I must avoid referencing the workspace->global_tags
and workspace->tags_array, because that's what's slowing down the
python plugin (it seems to do stuff with getattr() for each element even
if no python code actually accesses the elements). This is the main
reason for the abstraction via TM_QUERY_SOURCE_*

Isn't it access to individual TMTag elements of the array which is slow rather than just referencing the whole array? The TMTag elements would be accessed inside the C code which should still be fast.

For your idea to get tags for a specific document, I'd suggest a new filter.
gint tm_query_add_source_file(TMQuery *q, TMSourceFile *source_file);

I'd say don't add much more now, it can be added if someone needs it.

Here shows the strength of the TMQuery interface. Constructors and
filters can be added painlessly, without breaking existing users.

We probably see different things. I see 350 lines of new code which "does nothing" and what I like about Geany is there's very little code like this and it avoids various adaptors, interfaces and similar design patterns adding lots of "nothing doing" code with very well hidden "something".

Take this as my personal rant only; I have a very bad experience maintaining and evolving an enterprise system consisting of such a code. Geany's code is fortunately very direct and easy read and maintain and adding TMQuery won't cause any big disaster.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.