<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=811085" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/elextr">@elextr</a> the annoying part is that it brings an extra bundled copy of GNU Regex for platforms that don't have <code>regcomp()</code> (Windows is the most obvious candidate), yet GLib already does something very similar to provide GRegex.  So on some situations we could end with 2 copies of it <g-emoji class="g-emoji" alias="confused" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f615.png">😕</g-emoji></p>
<p>Currently we have a GRegex-based version of it, but it's not necessarily 100% compatible, and certainly doesn't have all the new stuff from upstream.  The question <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=713965" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/techee">@techee</a> raises is: is it worth maintaining this for the few parsers that use it?  What should we do?<br>
To be fair, the most important use case for upstream is dynamic parser definition (with various command-line switches) allowing to create parsers fairly easily for fairly simple things (although it got more and more powerful lately) -- and we don't have support for this, at least not yet.</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/2018#issuecomment-453920607">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ-aUWDGOOm7awopLCzJ8qAN7kTwEks5vDDQRgaJpZM4ZXOnd">mute the thread</a>.<img src="https://github.com/notifications/beacon/ABDrJ1v-q6D_RTxOmXlQkQdTAWPGIhNPks5vDDQRgaJpZM4ZXOnd.gif" height="1" width="1" alt="" /></p>
<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://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@b4n in #2018: @elextr the annoying part is that it brings an extra bundled copy of GNU Regex for platforms that don't have `regcomp()` (Windows is the most obvious candidate), yet GLib already does something very similar to provide GRegex.  So on some situations we could end with 2 copies of it :confused: \r\n\r\nCurrently we have a GRegex-based version of it, but it's not necessarily 100% compatible, and certainly doesn't have all the new stuff from upstream.  The question @techee raises is: is it worth maintaining this for the few parsers that use it?  What should we do?\r\nTo be fair, the most important use case for upstream is dynamic parser definition (with various command-line switches) allowing to create parsers fairly easily for fairly simple things (although it got more and more powerful lately) -- and we don't have support for this, at least not yet."}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/2018#issuecomment-453920607"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/geany/geany/pull/2018#issuecomment-453920607",
"url": "https://github.com/geany/geany/pull/2018#issuecomment-453920607",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>