How to escape characters?

[embs]

Hello!

I'm trying to exactly match some strings like "c*". Example:

filter = LanguageFilter::Filter.new matchlist: ["c\*"]

puts filter.match?('This excerpt c* should match.')
puts filter.match?('But this c should not.')

I've tried the regexes c[*] and c\* (which works properly when testing them on Rubular) but they didn't work. 😕

Many thanks!

[chrisvfritz]

Hmm... try "c\\*" - it should escape the backslash, to ensure that it isn't swallowed by the string and is passed on directly to the regex.

[embs]

This way neither one matches:

filter = LanguageFilter::Filter.new matchlist: ["c\\*"]
filter.match?('This excerpt c* should match.')
#=> false
filter.match?('But this c should not.')
#=> false

I've taken on another attempts but couldn't manage it yet.

[embs]

The problem seems to be the wrapper regex: when we use

c\*

it is translated into

\bc\*\b

which fails because an asterisk (like in "c*") is not considered a word boundary (required by the \b matcher).

It's possible to achieve desired behavior with the creative_letters option:

filter = LanguageFilter::Filter.new matchlist: ['c\*'], creative_letters: true
filter.match?('This excerpt c* should match.')
#=> true
filter.match?('But this c should not.')
#=> false

But README states that this option is not advisable and I wouldn't like to enable it only for matching some few edge cases.

Would it be viable to change the wrapper regex? With maybe something like

(\b|\B)

?

[chrisvfritz]

Hmm, I believe that would actually match everything, as \B matches everything that \b does not, which could cause quite a few issues. For example, filtering for "ass" would also match "mass" and "assets". A better compromise might be to replace \b with [\b\s], though this would be a breaking change that could have unintended consequences. I'd recommend trying it out in a fork though - it may meet your needs.

[embs]

Thanks, @chrisvfritz. You're completely right about the \B idea.

I've been searching around for solutions and ended up with a simpler version of the CREATIVE_END_REGEX which would meet my purposed use cases. #6