Thanks for the improvements! I am still personally a little hesitant to merge this for the reasons mentioned in#163 - these options are not taken into account by the parser. So,fancy-regex parses the pattern (without knowing about ignore whitespace mode for example), then if it contains fancy features, builds a VM and delegates some parts of the matching toregex-automata. But this means that if users/consumers start relying on these new options, some regular expressions will be matched incorrectly.
Concrete example - this test panics when it shouldn't:

#[test]fncheck_ignore_whitespace_option_fancy(){let builder =RegexBuilder::new(r"(?=test    foo)").ignore_whitespace(true).build();let test_text =r"testfoo";match builder{Ok(regex) =>assert!(regex.is_match(test_text).unwrap_or_default()),        _ =>panic!("builder should be able to compile with ignore whitespace option"),}}

This test doesn't panic when it should:

#[test]fncheck_ignore_whitespace_option_fancy_wrong(){let builder =RegexBuilder::new(r"(?=test    foo)").ignore_whitespace(true).build();let test_text =r"test    foo";match builder{Ok(regex) =>assert!(regex.is_match(test_text).unwrap_or_default()),        _ =>panic!("builder should be able to compile with ignore whitespace option"),}}

Ok I think I'm beginning to piece my head around what is going on.

WRT to 163 - Passing the RegexOptions only has partial success, it appears to work on the email but doesn't help with the test case you mention here.

I was wondering if a better approach might be to instead use the AST / Parsed Expression.
With has nodes such as.

Literal {    /// The string to match    val: String,    /// Whether match is case-insensitive or not    casei: bool,},

Would it be crazy to use to this AST / modify this tree ?

e.g. with this example

RegexBuilder::new(r"hello")
.case_insensitive(true)
.build();

Could the Tree be modified to consider any options ? Since the options would be set a global level ?

Perhaps this could be then be used to modify the regex. I would imagine that in case a regex is determined to be "fancy" the tree is passed to the automata library and for simple regex the passed expression could be modified to include the option
e.g. (?i)hello would be passed.

Wrapping nodes in(?i) should already be handled by the code which delegates to regex-automata. The main thing we need to achieve is, as you say, getting the AST correct. We should be able to do this by setting initial flags when parsing the regex pattern into an AST.

Wrapping nodes in(?i) should already be handled by the code which delegates to regex-automata. The main thing we need to achieve is, as you say, getting the AST correct. We should be able to do this by setting initial flags when parsing the regex pattern into an AST.

Ok I think I've got a clearer understanding of more or less what is needed. I will park this for now and see if I can look more at 163 and the AST. Since that appears to be more of a key for things working consistently.

Thanks@keith-hall.

Yeah I agree and commented as much. Let me see if there is some way to address that.

@keith-hall do you want to prepare a PR for doing the next release? I think you have the most changes to be documented in the CHANGELOG :).