[Github-comments] [geany/geany] New tagmanager query module (#1187)

[Jiří Techet]

> These two things are trivial to do, and quite a bit better from plugins if using an actual language support library (libclang, libpython, libvala, etc).

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.

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.

> Most of things wrong with it could be solved by using proper language support libraries, and if they're provided by plugins, why would anyone not using them care?

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. 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. So which way do you plan to solve it?

> Uh...that's exactly what TagManager/CTags is right now, and in some cases it doesn't work well at all. Moving such stuff to plugins (maybe a core plugin) would only have the effect of greatly simplifying Geany's core code, leaving it with just a few hooks and farming out language-specific support to plugins, which can do a much better job without bloating or making the core so complex.

The purpose of https://github.com/geany/geany/pull/1160 and following pull requests is to make ctags identical to upstream ctags at which point the ctags directory will be just external dependency we don't have to maintain in Geany and just grab the upstrem version. 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. 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.

> That doesn't make much sense, if people are using it for scripting languages, and developers can add proper support for those languages, then the largest percentage of users stand to benefit.

Again, it depends what way you want to implement it. My impression was you wanted to make some super-generic TM managing all the symbols regardless in what format they are. I don't think it's doable without making the code crazy. 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.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1187#issuecomment-242966614
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160828/f219ad49/attachment.html>