Case Sensitivity (revisited) and Locality

[micage]

I get wrong suggestions (more often than not). Here are two examples:

1. Image concerns Locality and precedence of tokens before vs. after:
   The correct result for the first image should be [const, ...]. There are some "copy" in the file but much further away (30 lines) from the cursor. I give some points to consider: "const" is a keyword, this should give a bonus. In the line above the cursor there is a "const", this should count more then the occurrences that comes x lines after the cursor line. What I mean is that words typed before should have more bonus/strength than words that comes after.

2. Image concerns Case Sensitivity and Locality:
   The correct result should be: [NODE_LABEL_CLASS, NODE_CLASS, ...]

Built-In Provider is enabled, Use Alternate Scoring is enabled, Use Locality Bonus is enabled, Atom version is: 1.12.7, Autocomplete-Plus version is: 2.31.4, no exotic plugins, everything up-to-date.

Is there an option to enforce case sensitivity (anyway the default behavior should prefer case sensitive matches)?
Is there a way to control which tokens/files autocomplete chooses from?
Would it be possible that we get some more options to tweak things a bit (e.g. locality bonus strength, token precedence before/after, case sensitivity)?

Failing to give correct matches in this easy cases makes Atom-Autocomplete quite a frustrating user experience and let me wistfully think back to the days when I could use Visual Studio's Autocomplete ... just joking. I'd really love to see it working the way it should and don't want to miss neither Atom nor Autocomplete.

[winstliu]

@jeancroy

[jeancroy]

@micage

Ok first screenshot, shorter version wins over locality bonus.
Information like "const" is a keyword is a nice way to think but we are miles from that, autocomplete is not syntax aware. We could try to bump locality bonus.

Second screenshot. It's complicated.
First thing you see is a snippet. Long story short snippet are always on top.

More detailed story is that there's different autocomplete sources and for each source, result are sorted. But then sorted result are juste appended one after the other depending of the source. This explain note. It may explain node / none as, as you can see, in a vanilla environnement they come after uppercase.

One thing I can do to help with second screenshot is an option to strictly enforce uppercase. (while lowercase will prefer other lowercase but allow uppercase)

[micage]

I understand that there are millions of use cases and you try to serve them all. And you cannot change behaviour of things that a lot of people depend on. But making it optional should do no harm.

The point is that I know my code best and I do exactly know what tokens i want to get autocompleted (80% tokens of the file at hand):

1. lengthy constants e.g. "NODE_LABEL_CLASS"
2. local function and variable names
3. API calls like e.g. window.requestAnimationFrame. If I type "window." and have not typed it before there are no proposals.
4. Very rarely use of snippet autocomplete

How can I exclude autocomplete sources that leads to wrong proposals? Which are used?

How can I include sources that I really use a lot?
While writing front-end code in Javascript/ES6 for example using the Web API there are a couple of tokens to include. https://developer.mozilla.org/en-US/docs/Web/API
Maybe that's miles away. I think one of the main purposes for developing Typescript was to get context specific autocomplete.

What about having an option to prefer code over snippets or have a snippet convention that does not start like a normal token (e.g. "+no" completes to "// NOTE:", "+if" completes to conditional snippet).

Prefer Case Sensitive Proposals would definitely be a must have and would spare me of a lot of wrong proposals.

Tweaking locality as an option would also be helpful.

[jeancroy]

[List of ordering]

Like you I rarely use snippet so I tend to disable it. Both for the snippet-first policy and some conflict key binding.

For the other, things in the ordering suggestion, code intelligence is not there yet.

Prefer Case Sensitive Proposals

This feature is already present and doing well, see my vanilla install screenshot.
However when everything is mixed together it may not be enough.
The one bigger hammer that I have at my disposition is to remove some results that does not match case.
Namely uppercase means uppercase, lowercase means anything but prefers lowercase.
I'm working on this bigger hammer.

How can I include sources that I really use a lot.

Snippet and proposal that come with language definition are two ways.
Alternatively there's been a few talk of maintaining a list of frequent / recent autocompletes.
That last feature would handle nicely such a use case.

What about having an option to prefer code over snippets.
Tweaking locality as an option would also be helpful.

My experience with atom team is that they really want to avoid the option panel to explode.
So they tend to avoid options unless necessary especially since those are quite specific, maybe a bit obscure.

I can however attest that there's has been little time spent tweaking locality and alternate scoring.
Mostly because it's hard to write specs. How much of a bad result are we willing to accept versus how much proximity. If it's too high bad result creep top of suggestion for no apparent reason. If it's too low issue like yours pop up. Right now it's basically a tie breaker, and mostly concern things a few lines around cursor. (Something 30 or 300 lines away are basically equally out of range for the mind)

If you want to play with it, it's there

---

Lastly I want to say that basically I maintain a fuzzy string sorting library and I'm not part of atom team. While I try to be helpful, there are some part of autocomplete plus that may need some rework to give the best sorting results. It's a bit complex because there's so many plugin author for that.

[micage]

Thank you very much for your detailed answer. I know that it's impossible to please everyone. There has to be compromises. Making good proposals just based on token/string analysis is hard compared to a syntactical one (based on a type system or prototype chain).

Prefer Case Sensitive Proposals

This feature is already present and doing well, see my vanilla install screenshot.

Could you plz give me a link. I cannot find this option. I can only see this screenshot:

[micage]

Is it "Use Strict Matching for Built-In Provider"?

[jeancroy]

What I meant Is that it's on out of the box. So I'm always surprised a bit when people find case where it's out of order. The screenshots I talked about is on my first reply.

…

On Tue, Dec 20, 2016, 17:51 micage ***@***.***> wrote: Is it "Use Strict Matching for Built-In Provider"? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#806 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMLCEpCHujcU8BObtuAQwwU2pCgLJ4b4ks5rKFvygaJpZM4LPZKl> .

[micage]

I will push a "Write your own Auto Complete" on my agenda. No sarcasm intended. Just to make sure it's working exactly the way I want. Nonetheless, thanks again.

[jeancroy]

@micage
I'm sorry if I've been a little to fast saying there's no Issue. I was mainly checking for an issue inside the library I maintain but you obviously have the issues shown in your screenshots so maybe there's way we can investigate those.

If you want to Improve ordering, out of my head here's 3 places that I know need some works.

1. Provider ordering. Snippet completion before object completion #465

   Basically this is the issue you have with snippet being on top. To sort across boundaries all providers must agree on a common definition of how good a result is. Alternative hack is to have a sort for the best of each category and that define the order of the whole block.

2. Provider, suggestion initial ordering. Provider initial ordering  #653

Autocomplete assume the initial list have some degree of meaning. For example go language and python have smart suggestion tools that are implemented in atom plugins. However a lot of source have dumb suggestion (eg keyword list built in atom language file, see php, or snippets). Suggestion is dumb as in sorted in alphabetical order. In those case the 'preserve ordering' behavior give a compromise between best match and alphabetical order, in most case this end up dumbing down the results.

Depending on how alphabetical order work with capitalisation this can mess with proper casing.
(Eg sort 'A' is ascii '65', 'a' is ascii '97', 'Z' is ascii '90' does 'a' follow between 'A' and 'B' or after 'Z' ?)

3. Language aware suggestion.

Basically atom default behavior is "dumb" but universal across language. However it support plugins for language awareness.

I think one of the main purposes for developing Typescript was to get context specific autocomplete.

Where you using atom-typescript ?

---

On a side note I only tried to reproduce your example with vanilla autocomplete and javascript language, maybe there's more information you can give to reproduce.