<blockquote>
<p>For my GI use case I must avoid referencing the <code>workspace->global_tags</code><br>
and <code>workspace->tags_array</code>, because that's what's slowing down the<br>
python plugin (it seems to do stuff with getattr() for each element even<br>
if no python code actually accesses the elements). This is the main<br>
reason for the abstraction via <code>TM_QUERY_SOURCE_*</code></p>
</blockquote>

<p>Isn't it access to individual TMTag elements of the array which is slow rather than just referencing the whole array? The TMTag elements would be accessed inside the C code which should still be fast.</p>

<blockquote>
<p>For your idea to get tags for a specific document, I'd suggest a new filter.<br>
<code>gint tm_query_add_source_file(TMQuery *q, TMSourceFile *source_file);</code></p>
</blockquote>

<p>I'd say don't add much more now, it can be added if someone needs it.</p>

<blockquote>
<p>Here shows the strength of the TMQuery interface. Constructors and<br>
filters can be added painlessly, without breaking existing users.</p>
</blockquote>

<p>We probably see different things. I see 350 lines of new code which "does nothing" and what I like about Geany is there's very little code like this and it avoids various adaptors, interfaces and similar design patterns adding lots of "nothing doing" code with very well hidden "something".</p>

<p>Take this as my personal rant only; I have a very bad experience maintaining and evolving an enterprise system consisting of such a code. Geany's code is fortunately very direct and easy read and maintain and adding TMQuery won't cause any big disaster.</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-242368212">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ0nn80flXi69pk9KNBzimllEHze7ks5qjYpLgaJpZM4JqVBL">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJx9ApVfD1FZqIX3miyoQIVQJJag-ks5qjYpLgaJpZM4JqVBL.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-242368212"></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 For my GI use case I must avoid referencing the `workspace-\u003eglobal_tags`\r\nand `workspace-\u003etags_array`, because that's what's slowing down the\r\npython plugin (it seems to do stuff with getattr() for each element even\r\nif no python code actually accesses the elements). This is the main\r\nreason for the abstraction via `TM_QUERY_SOURCE_*`\r\n\r\nIsn't it access to individual TMTag elements of the array which is slow rather than just referencing the whole array? The TMTag elements would be accessed inside the C code which should still be fast.\r\n\r\n\u003e For your idea to get tags for a specific document, I'd suggest a new filter.\r\n`gint tm_query_add_source_file(TMQuery *q, TMSourceFile *source_file);`\r\n\r\nI'd say don't add much more now, it can be added if someone needs it.\r\n\r\n\u003e Here shows the strength of the TMQuery interface. Constructors and\r\nfilters can be added painlessly, without breaking existing users.\r\n\r\nWe probably see different things. I see 350 lines of new code which \"does nothing\" and what I like about Geany is there's very little code like this and it avoids various adaptors, interfaces and similar design patterns adding lots of \"nothing doing\" code with very well hidden \"something\".\r\n\r\nTake this as my personal rant only; I have a very bad experience maintaining and evolving an enterprise system consisting of such a code. Geany's code is fortunately very direct and easy read and maintain and adding TMQuery won't cause any big disaster."}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/1187#issuecomment-242368212"}}}</script>