<p><a href="https://github.com/b4n" class="user-mention">@b4n</a> I have a few questions. First, forgot to mention the patches at the beginning are yours from</p>

<p><a href="https://github.com/b4n/geany/commits/ctags-tag-entry">https://github.com/b4n/geany/commits/ctags-tag-entry</a></p>

<p>I had to recreate them because of the new ctags location and added attribution in the comment. Hope it's fine with you.</p>

<p>Second, our ctags now uses these glib calls:</p>

<p>g_malloc<br>
g_free<br>
g_fopen<br>
g_try_malloc<br>
g_strv_length<br>
g_strerror<br>
g_realloc<br>
g_stat<br>
g_lstat<br>
g_warning</p>

<p>Is it OK to convert them to corresponding C stdlib or POSIX calls which uctags uses? My feeling is these were introduced as part of some "let's use glib calls everywhere in Geany" commit but we should keep ctags separate from Geany and have as little changes as possible compared to uctags. Is there any danger of mixing glib functions and their POSIX variants? (My guess is no as these seem to be just thin wrapper around the POSIX calls but I might be wrong.)</p>

<p>This leads me to another glib thing - GRegex. I know Nick introduced it to fix some prformance problem on Windows at that time (which might be gone by now) and personally I'd prefer to revert it back to GNU regex to avoid extra diffs to uctags. We now have just 3 regex parsers:</p>

<ul>
<li>HTML</li>
<li>Cobol</li>
<li>Actionscript</li>
<li>(R has an ifdef allowing it to switch between regex parser and hand-written parser but we don't use the regex part at the moment)</li>
</ul>

<p>Cobol and Actionscript are "who cares" but HTML is definitely important and would badly deserve a hand-written parser because the regex parsers will always be too slow. For comparison, all *.hpp files from boost take 5s to parse; boost's HTML documentation takes 15s to parse. I think creating a super-simple hand-written HTML parser that does just the same as the regex parser shouldn't be that hard and would be worth it (I might do it in the future unless <a href="https://github.com/elextr" class="user-mention">@elextr</a> beats me ;-).</p>

<p>Yeah and finally the "merge soon" I mentioned was just relative to other patches affecting the ctags directory - it meant only "merge sooner than anything else in ctags" otherwise we get bad conflicts.</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/1160#issuecomment-237510285">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJzzU-ncc9RD78dgrr6HwAVTPRikjks5qcblEgaJpZM4JbITK">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJwHHsaCpyLo76nq6OXso4WOtX56Zks5qcblEgaJpZM4JbITK.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/1160#issuecomment-237510285"></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://assets-cdn.github.com/images/modules/aws/aws-bg.jpg","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 #1160: @b4n I have a few questions. First, forgot to mention the patches at the beginning are yours from\r\n\r\nhttps://github.com/b4n/geany/commits/ctags-tag-entry\r\n\r\nI had to recreate them because of the new ctags location and added attribution in the comment. Hope it's fine with you.\r\n\r\nSecond, our ctags now uses these glib calls:\r\n\r\ng_malloc\r\ng_free\r\ng_fopen\r\ng_try_malloc\r\ng_strv_length\r\ng_strerror\r\ng_realloc\r\ng_stat\r\ng_lstat\r\ng_warning\r\n\r\nIs it OK to convert them to corresponding C stdlib or POSIX calls which uctags uses? My feeling is these were introduced as part of some \"let's use glib calls everywhere in Geany\" commit but we should keep ctags separate from Geany and have as little changes as possible compared to uctags. Is there any danger of mixing glib functions and their POSIX variants? (My guess is no as these seem to be just thin wrapper around the POSIX calls but I might be wrong.)\r\n\r\nThis leads me to another glib thing - GRegex. I know Nick introduced it to fix some prformance problem on Windows at that time (which might be gone by now) and personally I'd prefer to revert it back to GNU regex to avoid extra diffs to uctags. We now have just 3 regex parsers:\r\n\r\n- HTML\r\n- Cobol\r\n- Actionscript\r\n- (R has an ifdef allowing it to switch between regex parser and hand-written parser but we don't use the regex part at the moment)\r\n\r\nCobol and Actionscript are \"who cares\" but HTML is definitely important and would badly deserve a hand-written parser because the regex parsers will always be too slow. For comparison, all *.hpp files from boost take 5s to parse; boost's HTML documentation takes 15s to parse. I think creating a super-simple hand-written HTML parser that does just the same as the regex parser shouldn't be that hard and would be worth it (I might do it in the future unless @elextr beats me ;-).\r\n\r\nYeah and finally the \"merge soon\" I mentioned was just relative to other patches affecting the ctags directory - it meant only \"merge sooner than anything else in ctags\" otherwise we get bad conflicts."}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/1160#issuecomment-237510285"}}}</script>