<blockquote>
<p>I guess it's kind of safe to assume now that there won't be too many changes in this pull request, right?</p>
</blockquote>
<p>yeah, should be pretty close to merge.</p>
<blockquote>
<p>Question: there seem to be quite massive changes in the lregex.c/h upstream and this one isn't so trivial to merge because we use GRegex and ctags uses GNU Regex. Syncing this would mean taking care of the different semantics of the two regex libraries which might be quite a lot of work. What if we just removed support of regex-based parsers from Geany and #if0'd the bodies of all functions from lregex.c? Currently we use regex parsers for HTML, Cobol and ActionScript - for HTML there's a token-based parser upstream we can use which would mean we'd just kill parsing support for Cobol and ActionScript. I may be biased but I don't think these particular languages are so important to justify all the work related to the regex-based parsers.</p>
</blockquote>
<p>Hum… on one hand it's kind of sad not to allow regex parsers because some u-ctags parser use it (12 built-in ones apparently), and it makes creating a basic parser easier; on the other I already said that I'd rather not have an additional copy of the GNU regex lib and I understand that having a GRegex module is trickier.  Ideally we'd submit an alternative GRegex-based engine upstream and keep it up-to-date over there.</p>
<p>Anyway, for the case at hand: I don't really like dropping support for languages we have, but me being myself I'll give a shot at translating those parsers as "real" ones, which should make them faster as well, and unless they have highly complicated regexes, it should be fairly easy.<br>
So I'd say you can for now assume we can at least temporarily drop lregex, and we'll see what we can do after.</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/1263#issuecomment-447985471">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ9oZri4yJpq2WotyodcyKvxID18Iks5u5_z8gaJpZM4KXvBh">mute the thread</a>.<img src="https://github.com/notifications/beacon/ABDrJ2ljS4cknUerW1mfziwEJQu5hdsLks5u5_z8gaJpZM4KXvBh.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 #1263: \u003e I guess it's kind of safe to assume now that there won't be too many changes in this pull request, right?\r\n\r\nyeah, should be pretty close to merge.\r\n\r\n\u003e Question: there seem to be quite massive changes in the lregex.c/h upstream and this one isn't so trivial to merge because we use GRegex and ctags uses GNU Regex. Syncing this would mean taking care of the different semantics of the two regex libraries which might be quite a lot of work. What if we just removed support of regex-based parsers from Geany and #if0'd the bodies of all functions from lregex.c? Currently we use regex parsers for HTML, Cobol and ActionScript - for HTML there's a token-based parser upstream we can use which would mean we'd just kill parsing support for Cobol and ActionScript. I may be biased but I don't think these particular languages are so important to justify all the work related to the regex-based parsers.\r\n\r\nHum… on one hand it's kind of sad not to allow regex parsers because some u-ctags parser use it (12 built-in ones apparently), and it makes creating a basic parser easier; on the other I already said that I'd rather not have an additional copy of the GNU regex lib and I understand that having a GRegex module is trickier.  Ideally we'd submit an alternative GRegex-based engine upstream and keep it up-to-date over there.\r\n\r\nAnyway, for the case at hand: I don't really like dropping support for languages we have, but me being myself I'll give a shot at translating those parsers as \"real\" ones, which should make them faster as well, and unless they have highly complicated regexes, it should be fairly easy.\r\nSo I'd say you can for now assume we can at least temporarily drop lregex, and we'll see what we can do after."}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/1263#issuecomment-447985471"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/geany/geany/pull/1263#issuecomment-447985471",
"url": "https://github.com/geany/geany/pull/1263#issuecomment-447985471",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>