atom
Added optional neverFilter tag to suggestions
If a suggestion has neverFilter = true then it will not be filtered out when the provider's filterSuggestions is true.
Description of the Change
Right now if you have filterSuggestions = true in your provider then any suggestion with a replacementPrefix will be filtered out unless the snippet also matches the replacement prefix. Take this example:
Lua does not support ++ or -- operators. I want to make a suggestion which will expand the user typing foo++ into foo = foo + 1. However, in this case we want to replace "++" with "= ..."; this works OK if filterSuggestions is disabled, but when it is enabled the filter eats this suggestion.
This fix works by checking for a neverFilter property in the suggestion; if it's set to true then the suggestion is kept by the filter method.
Alternate Designs
-
Never filter a suggestion list when it contains only one suggestion. Add this as the first line in filterSuggestions:
if (suggestions.length == 1) return suggestions -
Reverse this line:
const text = (suggestion.snippet || suggestion.text)so it readsconst text = (suggestion.text || suggestion.snippet)The user can then set the text property so that it matches the replacementPrefix, but keep the snippet property as what they want to appear (the snippet takes precedence for completion).
Both of these feel like they'd have unintentional knock-on effects, and neither are particularly obvious to the user.
Benefits
Gives the provider maker the ability to "force-through" a suggestion, ensuring it does not get filtered by filterSuggestions.
Possible Drawbacks
Unlike the two alternative designs, there is very little chance of adverse effect here. Slight bloat to the Provider suggestion api as it gains a property.
Applicable Issues
#777, can possibly be used to work around #781 and #615
@leroix Can you take a look at this? Not super versed on the API but it seems like this PR is fixing a bug and could enable much cooler autocomplete features.
@onelivesleft I've been trying to dig into this a little bit. I think maybe we shouldn't filter a suggestion just because the first character in the suggestion text doesn't match the first character of the prefix. I'm not sure what removing this would break though.
For the example you mentioned, I think you could add that functionality to the autocomplete-lua provider. The provider would check if the prefix matches the pattern you mentioned and return foo = foo + 1 as a suggestion.
