Am 29.08.2016 um 17:52 schrieb Jiří Techet:<br>
&gt;     I don&#39;t see why TM couldn&#39;t be improved to support other, AST-based<br>
&gt;     parsers. Sure TM is lacking now but we cna fix that. I don&#39;t think<br>
&gt;     it&#39;s too much work.<br>
&gt;<br>
&gt; Good, modify tag array merging<br>
&gt;<br>
&gt; https://github.com/geany/geany/blob/master/src/tagmanager/tm_tag.c#L375<br>
&gt;<br>
&gt; to work on trees that is similarly fast and let&#39;s talk then ;-).<br>
<br>
<br>
The plugin probably would provide a list, which it generated internally <br>
from whatever representation.<br>
<br>
<br>
&gt;<br>
&gt;     But coming back to this PR. I don&#39;t think the proposed query API is<br>
&gt;     affected by the above ideas. It&#39;ll always be used to return a list<br>
&gt;     of tags. If the TMTag structure changes for new features or are<br>
&gt;     subtrees instead of plain tags is a different story.<br>
&gt;<br>
&gt; As I think TM should be used for ctags-like tags, lists should be fine.<br>
&gt; (They would be insufficient if you needed some AST information, e.g. for<br>
&gt; code completion.)<br>
<br>
<br>
Then TM should be improved to hold sufficient information. auto <br>
completion leaves a lot to be desired even for ctags based tags so <br>
there&#39;s definitely work to do on the TM side.<br>
<br>
I wonder what makes you guys think this list vs tree(AST) makes things <br>
fundamentally unworkable? It&#39;s a complete non-issue to me. It&#39;s just a <br>
representation that can be converted as needed.<br>
<br>
Anyway, as @elextr also said, I think that even if TM would use a <br>
completely different internal representation (such as a tree), the query <br>
results would most likely still be a list. Similarly to DB queries, <br>
which also return flat tables. So the list vs tree discussion becomes <br>
orthogonal to this PR.<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<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-243358385">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ3rCvnYpVEUhEFTx_4VyAEXkbmjjks5qk95igaJpZM4JqVBL">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJyC2w8FMP7QxApJK94ehA8h1AQjKks5qk95igaJpZM4JqVBL.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-243358385"></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":"@kugel- in #1187: Am 29.08.2016 um 17:52 schrieb Jiří Techet:\n\u003e     I don't see why TM couldn't be improved to support other, AST-based\n\u003e     parsers. Sure TM is lacking now but we cna fix that. I don't think\n\u003e     it's too much work.\n\u003e\n\u003e Good, modify tag array merging\n\u003e\n\u003e https://github.com/geany/geany/blob/master/src/tagmanager/tm_tag.c#L375\n\u003e\n\u003e to work on trees that is similarly fast and let's talk then ;-).\n\n\nThe plugin probably would provide a list, which it generated internally \nfrom whatever representation.\n\n\n\u003e\n\u003e     But coming back to this PR. I don't think the proposed query API is\n\u003e     affected by the above ideas. It'll always be used to return a list\n\u003e     of tags. If the TMTag structure changes for new features or are\n\u003e     subtrees instead of plain tags is a different story.\n\u003e\n\u003e As I think TM should be used for ctags-like tags, lists should be fine.\n\u003e (They would be insufficient if you needed some AST information, e.g. for\n\u003e code completion.)\n\n\nThen TM should be improved to hold sufficient information. auto \ncompletion leaves a lot to be desired even for ctags based tags so \nthere's definitely work to do on the TM side.\n\nI wonder what makes you guys think this list vs tree(AST) makes things \nfundamentally unworkable? It's a complete non-issue to me. It's just a \nrepresentation that can be converted as needed.\n\nAnyway, as @elextr also said, I think that even if TM would use a \ncompletely different internal representation (such as a tree), the query \nresults would most likely still be a list. Similarly to DB queries, \nwhich also return flat tables. So the list vs tree discussion becomes \northogonal to this PR.\n"}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/1187#issuecomment-243358385"}}}</script>