autocomplete-plus icon indicating copy to clipboard operation
autocomplete-plus copied to clipboard

Add a global minimum word length option.

Open nmote opened this issue 10 years ago • 6 comments

Some discussion has already been happening in #335, but since it's off topic from that original issue I hope to move the discussion here. @benogle I know you have partially nixed this idea already but I was mostly done writing this up when you posted so I figured it couldn't hurt. I'm definitely not trying to be pushy so feel free to close if you don't like any of my ideas :smile:

I would like there to be a configurable minimum word length option that applies to all providers. This should likely be a different setting because minimumWordLength historically applies only to the built-in provider. I propose the name globalMinimumWordLength.

@antcodd pointed out that this is difficult to do because different providers use different prefixes. To work around this, I have a few different suggestions. Comments are welcome.

  • Providers could simply opt-out of this entirely. We could add a new provider property named ignoreMinimumWordLength or similar. Setting this to true would mean that providers would get requests even when the prefix is shorter than the minimum word length. It would then be up to them to figure out whether to return results based on their replacementPrefix and the value of globalMinimumWordLength. Basically, if they had this property they would function exactly like they do today.
  • Under the tips for providers, there is a section that suggests how to compute a new prefix. We could take it further and actually allow providers to have another method that only computes the replacementPrefix. The computed replacementPrefix would be passed into getSuggestions so that the providers wouldn't have to duplicate the work there, but more importantly, autocomplete-plus could use the computed prefix to compare against the minimum length option. This is the option that I prefer.
  • We could call the autocomplete providers just like is done today, and filter the results based on the replacementPrefix that they pass back. This has the advantage that providers don't have to take any action, but it means that we may be doing a lot of unnecessary work.

nmote avatar Oct 13 '15 21:10 nmote

I really think we should just use one setting (the current minimumWordLength setting), and if it makes sense for the provider to use the setting, then it should, otherwise the provider should just ignore it.

  • I dont want to add more settings
  • I dont want to prescribe what providers should implement, especially more than one setting

Providers could even use minimumWordLength only In some cases. e.g. a clang provider maybe adheres to it when context-less (like typing a global or local var), but ignores it after a . is typed and the cursor is in the object's context.

benogle avatar Oct 15 '15 00:10 benogle

Can we discuss the default, then? Personally I would prefer 0 or 1 characters, and I would be hesitant to make the Flow autocomplete provider respect the setting because the default is 3. I'm concerned that it would degrade the experience for most people and they wouldn't even bother to check the settings. I realize, however, that I may not be representative of all developers. How did you settle on the default of 3?

nmote avatar Oct 19 '15 16:10 nmote

Why does the flow provider need less than 3 characters?

The goal was to reduce noise. 3 characters felt like a good choice after trying other numbers for a while. I would be open to changing it to 2. 1 char seems excessive; how often is the top completion the correct one after typing only a single character?

benogle avatar Oct 19 '15 20:10 benogle

I don't have solid data -- this is just guided by my own preferences. In my experience there are often only a handful of JavaScript object properties, and I like having them available immediately. Admittedly this is just my own preference and I don't know what most people like.

It looks like an activatedManually flag is passed to getSuggestions. I'll add that to the API wiki. Since that would allow results to be requested on demand, I would be satisfied with lowering the default to 2. I do think that quite often, two characters is enough to narrow down the list of results.

nmote avatar Oct 19 '15 21:10 nmote

Ok, I'm down with a default change to 2.

benogle avatar Oct 19 '15 21:10 benogle

To resurrect this issue, autocomplete-python has some deeply shitty behavior and I was very surprised that this setting did nothing. It actually shows suggestions on zero characters; if you type hello = , it will suggest:

image

It seems obvious that the default behavior across every provider should be obeying this setting. If they feel they have a good reason to violate it, fine, but the default should be obeying it.

willwhitney avatar Sep 15 '17 15:09 willwhitney