Trailing whitespace should not be trimmed

Thanks for reporting this issue!
However, I’m not convinced a change to this module is needed. It seems this is a requirement very specific to one particular way of creating suggestions, and if you want a trailing space in that case then you should just add it in the place where it is needed, in the Solr Suggester plugin class. You can easily detect this case by checking for $incomplete_key === '', and could then either just use the unchanged user input (which is not affected by splitKeys() at all, as far as I can see) or use the keys set on $query and append a ' ' character.

The code is admittedly a bit complicated, so I’m not 100% sure I understand all of it, but it seems like you have everything you need in the getAutocompleteSuggestions() to ignore anything splitKeys() does, if necessary.

@drunken monkey thank you for you input and you have some valid points, I could just create a custom plugin extend the "search_api_solr_suggester" and make those adjustment like you said. But trimming by default spaces in the "search_api_solr_suggester" plugin feels to me like the query is specific for some Solr lookup implementations, vs just allowing spaces and having the query to the Solr suggester raw as possible.

If you still find this an edge case, we can close both issue's and I will do a project specific implementation for it.

It’s not just about Solr, there are other backends that support autocomplete as well. I think this way of doing it was an abstract choice, not one tied to a specific implementation. As detailed, I think it passes along all the necessary information for implementations to calculate the appropriate suggestions any ways they see fit. Changing this now might have a small benefit for one specific implementation, but might actually be detrimental to others, while definitely causing a break in behavior that all/most implementations would need to address.

So, yes, I think I’ll close this as “won’t fix”. However, if the Solr Suggester doesn’t work correctly with the data currently, it seems like the other issue still makes sense. You just have to implement the fix in a way that doesn’t require changes to this module.