enable_split_word_search doesn't do anything if search_contains is true

[scott-census]

Setting enable_split_word_search: false is supposed to make the search match the whole word (i.e. start from beginning). In winnow_results, what it does if false is insert a '^' at the beginning of the regex--but it only does so if search_contains is also false (code is if (!(enable_split_word_search || search_contains)) .... This is the only place enable_split_word_search is referenced in the code, other than to set the internal variable.

I have to use search_contains: true because there are various non-alpha characters in my lists (like '+', ')', '-') and matches for them fail if they are supposed to be on word boundaries (I believe this is a known issue). But I would still like to match from the beginning. Seems like a bug to me that using search_contains prohibits matching from the start.

Steps to reproduce

Tell us how to reproduce this issue.

1. Create a list with options {enable_split_word_search: false, search_contains: true}

2. Try to search for something that occurs within a word but also at the beginning of a word

I created two demos to show this issue, one using the current version (1.7.0) and the other a build from master as of Aug 8, because they work differently when search_contains is true, but in both cases that condition will not work with the lists I have.
jsFiddle: Chosen 1.7.0
Plunker: Chosen master (Aug 3)

Additionally, they both show bugs when search_contains is true. In particular, the current master does not show the first two list items ('<01M' and '<10Y') as all (in addition to demonstrating the known issues with non-alpha characters). I haven't dug into that because I can't use that setting anyway.

Expected behavior

Perhaps enable_split_word_search would be better named search_from_beginning, but it should add the '^' to the regex regardless of the value of search_contains (in get_search_regex, line 408).

Actual behavior

Has no effect unless search_contains is false (which causes other problems in many cases).

Environment

• 1.7.0 and current master:

Additional information

I guess the current unreleased version is an improvement, although the addition of \b around the search term in the regex causes problems with a number of characters. However, dropping the items from the list altogether seems like an issue. In the 1.7.0 version, there is also a problem with those entries: they are displayed in the result list as only the alphabetic part ('M' and 'Y')

[Mikk3lRo]

IMHO what you suggest is as counter-intuitive as the problem you experience. Only difference is that enable_split_word_search=false would override search_contains=true instead of the other way around.

However, I think being able to set a custom word-boundary would be the most flexible way to solve this issue altogether. As it happens I just created a PR that will allow you to do that (among a few other improvements to the flexibility of searches).

Take a look at #2894 and see if I'm correct in assuming that this will solve your issue?