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.

Doesn't the regex syntax differ between them? If so, it would mean also to support different regexes for all the regex-based parsers which is probably not going to happen.

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.

The diff against ctags looked really scary but maybe if I just took the uctags version and GRegex-ified it, it might not be so bad. I just wasn't particularly motivated by the languages we use - ActionScript (which is used by Flash and is about to die) and Cobol which might be used by some legacy mainframe software but that's about it. I also don't think it's worth writing proper parsers for these. It might be different if we want to use more regex-based parsers from uctags but my current thinking is something like: "If a language is popular enough, it probably has a proper parser in uctags and then we should support it in Geany. If the language is not popular enough to have an uctags parser, there's no need to support it in Geany".

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.

This is what I did in the ctags_sync3 branch.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.