Suggestions for "special" characters.

We've found some quircky behavior in the rendering of the suggestion list, when handling a term that is part of an URL.

We noticed that once someone entered the character "r" in the search box one of the suggestions was sportsphp which seems not to strange until you notice that the suggestion HTML also highlightes the "s"

<div class="apachesolr_autocomplete suggestion">
  <strong>s</strong>
  po
  <strong>r</strong>
  tsphp
</div>

Things got even weirder that when searching on the term "re" also provided sportsphp as suggestion.

<div class="apachesolr_autocomplete suggestion">
  <strong>sp</strong>
  ortsphp
</div>

"re" obviously isn't part of the term so this shouldn't be mached, and certainly not on "sp". This is confirmed by clicking on the suggestion and start a search for "sportsphp", the solr page will show a notice that no results are found.

We've tried to trace the issue but got stuck somewhere in the module. What we've found is the following:

When dumping the request send to Solr and running the query directly in Solr there are quite a bunch of results

This is the result when entering "r" in the autocomplete box.

You'll notice that there is a result for the suggestion regions_sports.php. When searching the database for this string, we'll find a result in one of the URL fields that are indexed for this site. So that we'll find this term for this given string is expected.

However when going deeper into the autocomplete module we can track the results into the
apachesolr_autocomplete_suggest() function, where things start to go wrong. When entering this function the found terms still contain the string regions_sports.php.

When building the matches array two things happen, first of all
$terms = preg_replace('/[_-]+/', ' ', $terms); which splits the term so now we'll have "region" and "sports.php". At this point the term is still good as it will match on the "OR". But two lines later we'll find
$term = trim(preg_replace('/['. PREG_CLASS_UNICODE_WORD_BOUNDARY .']+/u', '', $term)) which transforms sports.php into sportsphp which obviously doesn't exists and doesn't match anything.

The only reason I could think of that this is usable, is in case we'll have something like "sports. [new sentence]" where the point is actually the end of a sentence.

I haven't been able to think of a proper fix for this case, but it is a problem that suggestions are corrupted to the point where they aren't actually suggestions anymore.