Use GLib's regexp interface (backed by PCRE) #412
Conversation
|
I think this is a good idea. what we need is
|
a31b5fd to
6aebf0a
Compare
|
we (probably) need to conditionally use the raw flag. Two cases:
|
|
we should consider if it shouldn't be possible to disable the RAW mode? otherwise we cannot benefit from the unicode advantage in gregex |
|
Does this support negative lookahead? I'd like to try it, I get irssi from brew on OS X if that matters. |
|
@foice , see man pcresyntax, I assume that's the place to read about pcre and what it supports (it mentions negative look ahead) |
|
@LemonBoy @ailin-nemui how about using both regex systems in parallel for a while to let people adjust to the change and use a setting to switch between the two? It would make the codebase bigger for the time being but might not give users as much headache, or is there a library that you know of(I didn't find anything with google) that would allow conversion of POSIX regex to PCRE? |
Converting POSIX regex to PCRE would mean trying to emulate it while keeping bug-compatibility with it. Nope. Maybe it's a matter of adding backslashes to some characters and removing them from others, but we might end up learning about missed edge cases after releasing a new version breaks stuff. I don't want to go there. Better allow switching regex engines with a global setting. |
|
I would really like to see some test cases wrt. UTF8 and with and without the raw flags and some thoughts about how to go best about this (compile 2 regexen and match them depending on utf state?) there is also some secret unicode command flag in pcre iirc, does this apply? |
|
I will merge this, issues caused by that can then be found and solved later |
|
I really don't like the idea of replacing the regexp engine. |
|
It's a breaking change, and a subtle one at that. People will upgrade irssi and find their stuff stopped working for no particular reason. Let's not do that. The improvements brought by this change aren't worth it. I'd rather have it under a setting. |
|
how about making it a compile time switch |
Also remove the prototype for regex_match since it has been removed.
It was made redundant by the introduction of the pointer to the GRegex structure. Silence the compiler warning in textbuffer.c about preg being initialized by setting it to NULL.
Also, plugged a memory leak when retrieving the match position.
27d51d0 to
1f72b8e
Compare
|
dequis wrote:
Exactly this happened to me -- I realize that this is a compile-time edit: or, release notes should have been clearer about this. |
|
sorry for your inconvenience, I pushed for this change but dequis was against it. I added a further hint about it to the on-site release notes (cannot change the released notes anymore) would you like to expand on what regex broke and how you had to modify it? |
|
On Mon, Jan 09 2017 01:32:33 -0800, ailin-nemui wrote:
sorry for your inconvenience, I pushed for this change but dequis was against it. I added a further hint about it to the on-site release notes (cannot change the released notes anymore)
Thanks.
would you like to expand on what regex broke and how you had to modify it?
Sure. I was using \< to match a word boundary in some of my highlights,
and I had to replace that with the PCRE \b (\> is likely similarly
affected).
…--
Lauri Tirkkonen | lotheac @ IRCnet
|
Pros:
Cons:
This proposal is up for discussion 🎈
@ailin-nemui
I would really like to see some test cases wrt. UTF8 and with and without the raw flags and some thoughts about how to go best about this (compile 2 regexen and match them depending on utf state?) there is also some secret unicode command flag in pcre iirc, does this apply?