To me it looks more like a solution for your problem (which is fine) than something that would be needed in Geany. The current search functions in TM are indeed single-purpose for specific uses in Geany but there's no problem to grab one of the tag arrays, go through the elements and pick those you are interested in (one for loop, one if inside and this is more flexible than some extra API). The new API seems to be useful just to make the filtering fast in Python (and again, sounds like a fair reason).

Of course it's one solution for my problem. But I made it so that it's useful outside my problem space too.

I simply found that there are no plugin APIs for introspecting Geany's tags, other than giving access to the raw tag arrays. And the existing, un-exported functions are not suitable to become exported. So I felt the need to create a useful method to achieve that, which also solves my specific problem.

I need a solution for my problem, and a generic query interface is a lot better than adding even more special-purpose function and even adding those to the plugin API. My proposed solution can potentially cover so much more use cases that we should be well prepared for the future.

I'm not too keen on exporting any TM stuff FWIW. I'd like to see TM/Ctags as some kind of fallback tag handling that can be disabled by plugins who provide better filetype-specific support in the future. At least the one nice thing about the current TM for plugins is that it's a nice thin API that allows plugins to still accomplish whatever they want (KISS).

TM has no API for quering tags, except for the exposure of the raw arrays. Currently exported are methods to add/remove source files from the workspace. IIRC those where specifically added for ProjectOrganizer, in order to add tags for unopened documents.

Also, TM is no fallback. It's simply what we've got to manage our tags. In my opinion we should open it up more, in order to allow plugins to easily get involved in tag management. This includes methods to add tags via non-ctags mechanisms, but also for quering existing tags (from whatever source they may come from).

In fact, plugins shouldn't disable TM to do their own stuff. This will only cause pain since neither Geany itself or other active plugins can function properly in such a situation. Instead, all plugins should cooperatively work on the same tag management system (using proper APIs). I.e. a llvm/clang plugin should add tags to the tagmanager, so that my quickswitch plugin still does what it should do and Geany can show proper autocompletion and symbol sidebar.

You said you made it because you couldn't accomplish what you wanted in Python efficiently enough. That's where you usually would write a Python extension module to work around the inefficiencies.

I could implement a solution specifically for my plugin, somwhere yes. But I prefer a solution where everyone else can benefit as well. Besides, peasy is not python specific, it doesn't even use any pygobject APIs or has the necessary build system support for python-specific extension modules. I definitely won't introduce that if there are better alternatives.

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