<blockquote>
<p>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).</p>
</blockquote>

<p>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.</p>

<p>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.</p>

<blockquote>
<p>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?</p>
</blockquote>

<p>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?</p>

<blockquote>
<p>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.</p>
</blockquote>

<p>The purpose of <a href="https://github.com/geany/geany/pull/1160" class="issue-link js-issue-link" data-url="https://github.com/geany/geany/issues/1160" data-id="169007391" data-error-text="Failed to load issue title" data-permission-text="Issue title is private">#1160</a> 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.</p>

<blockquote>
<p>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.</p>
</blockquote>

<p>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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/pull/1187#issuecomment-242966614">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ0QvOYhcUXs9rMHM-FQTCok31U-Sks5qkV3AgaJpZM4JqVBL">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ2pep20P2gOymoZbaVp_3FUm4PX7ks5qkV3AgaJpZM4JqVBL.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/pull/1187#issuecomment-242966614"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@techee in #1187: \u003e 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).\r\n\r\nWell, 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.\r\n\r\nAlso 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.\r\n\r\n\u003e 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?\r\n\r\nAgain, 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?\r\n\r\n\u003e 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.\r\n\r\nThe 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.\r\n\r\n\u003e 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.\r\n\r\nAgain, 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.\r\n"}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/1187#issuecomment-242966614"}}}</script>