Well, it depends if you want to implement the symbol tree all by yourself or not. If not, you'll either have to map libclang symbols to TMTags or come up with some substitute used by both.

It's just a GtkTreeView. It could be as simple as Geany setting up the cell renderers and the model and then calling into a plugin to fill in the model.

Also I'm not sure how you plan to handle cases where you open a single C file which by itself doesn't compile and which isn't part of any project. I guess libclang won't be able to parse it right? Then TM should be used instead.

Indeed, there needs a way to inherit or fallback to basic (current) functionality.

Again, I don't know which way you plan to implement it - as I said, I think ASTs are incompatible with the linear tag lists generated by ctags.

I don't really see why. It wouldn't be hard to traverse the AST and generate a tags list, filling in the scope with the correct path/namespaces. IIUC Ctags and not TM is responsible for the broken scope support in Geany.

My feeling is it will require lots of new code on Geany's side, not the plugins side which I indeed don't care about, to make something generic.

The only thing that would need to be added to Geany is some hooks/callbacks/interfaces/whichever to get the plugin to provide the info. All of the complexity would be in the plugins (and not even since most language libraries make this stuff quite trivial to implement).

Indeed, there's some code in tagmanager which has to be maintained but if we want to keep support of all the languages we have, it will have to stay this way.

It doesn't have to stay in the core, it could become a core plugin, but it does have to be on by default and/or provide the baseline functionality. I only have an interest in augmenting the current functionality by plugins, I have no interest in making Geany not work as well out-of-the-box.

And no, I don't think it would be a good idea splitting ctags into 30 different plugins and maintain them separately and require users to install all of them if they want multi-language support.

Just one plugin, part of the core, and on by default.

If plugins just install hooks for specific features like autocompletion, symbol tree, etc. that should be pretty trivial on Geany side and it shouldn't be any problem.

That's the idea. The language support libraries already provide their own specific TM-like APIs, no point in re-inventing that generically when most of the needed features (filling in a treeview, filling in a listview, providing a location of declaration, etc) can be accomplished more easily on the plugin side if they have access to the actual language implementation libraries.

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