Wildcard pattern matching issue - bug or workaround?
Hello .... new list member looking for some comments/help! Thanks!
I have search patterns in my muttrc that look like this:
#Color index yellow for zip attachments
color index brightyellow black "~b \ name.{0,9}\=.{2,30}\.zip"
After my recent upgrade to SuSE 10.2 (mutt v1.5.13), this formerly working line
now results in an error message that results from using the '=' in the pattern.
Did I miss something somewhere about how to escape such characters,
or are they possibly documented somewhere as disallowed? Anyone know
any workarounds?
Thanks for any help anyone can offer.
<software_engineer_mode>
For the folks who might wish to dig a bit deeper into understanding
what changed, I downloaded 1.5.16 & reproduced the issue - the line
numbers in the following description are from 1.5.16.
Ultimately I tracked my problem down to THIS change:
http://dev.mutt.org/hg/mutt/diff/099507c0897a/init.c
pattern.c:mutt_pattern_comp expects pattern.c:eat_regexp to consume the complete
regular expression. However, line 272 in pattern.c:eat_regexp calls
init.c:mutt_extract_token(&buf, s, M_TOKEN_PATTERN | M_TOKEN_COMMENT)
Because the '=' is in my pattern, and mutt_extract_token breaks out of the
while on '=' if M_TOKEN_PATTERN is set, then the whole regex pattern is not
consumed, and mutt_pattern_comp tries to proceed with the remainder of the
pattern and fails.
I would have gone further & tried to fix this, but realizing that
mutt_extract_token is probably a much more generally used function,
I'm definitely afraid to tinker with it..... I _have_ verified that
pulling the '=' out of the check in init.c restores the desired behavior.
I can almost guarantee though that it'd screw something else up that
was the intended effects of that changeset!
Ok, now for the questions:
* Is this actually a bug?
* Is there a workaround?
* Are the _other_ characters (e.g. #, !, |, ~) in mutt_extract_token unuseable
in a pattern?
</software_engineer_mode>
Thanks!