Atom's autocomplete-plus has a feature which allows sorting suggestions by a "locality bonus", meaning that symbols in the document that are closer to the cursor are more likely to show up first.
For example, when I type "req" in a node file, the first thing that shows up is "requestAnimationFrame", when I usually want "require" instead. With this "locality bonus", "require" would end up being the first thing to show up, since it's found in the current file already, and probably only a line higher or lower. "requestAnimationFrame" would get pushed lower, since it's not in the file at all.
Apologies in advance if this is a duplicate, or if it's already implemented. I've searched and haven't seen any issue touching particularly on context awareness. It's one of the few features I miss from Atom.
Interesting, tho also spawning across extensions... In our world the first sort order depends on the suggestion provider (sortText) and we have seen requests against different extensions to sort by locality, like locals vs globals. In the same spirit textual suggestions can be improved. However, to implement this broadly the API should be extended to include the definition of a symbol being inserted and the us doing some uniform locality sort.
Similarly, when I write on node.js then instead of "require" the first in the list is "requestAnimationFrame", and no matter how much I select "require" the same thing every time.

At StackOverflow offer, to assign a snippet, but it does not seem to be the best solution:
https://stackoverflow.com/a/40129409/6011421
@dedmazayukr Can you try this with the setting "editor.suggestSelection": "recentlyUsedByPrefix",?
Thanks for Your reply, @jrieken , this partly solve the problem. Although it is strange why the in node.js requestAnimationFrame constantly in the top place:

This will land in September behind a new setting: "editor.suggest.localityBonus": true. With that sorting of suggestion depends on (in that order)
The locality itself is computed by the enclosing scope, think of {}-blocks in c-style languages. See the attached screen shot below. The suggestion wzz wins because it's inside the same scope, the outer scope has ware and wert, both have the same 'distance' and there the extension sort order (alphabetical) comes into play.

Awesome! Updated today. Good work, thank you.
@jrieken Is is possible to get the same kind of behavior for the "open file palette" (not sure if is called in that way) based on file proximity to the file that is opened?
Let's me explain, the problem is when you have a bunch of files with the same name in different folders:
- component-1
--- index.ts
--- component.tsx
- component-2
--- index.ts
--- component.tsx
- component-3
--- index.ts
--- component.tsx
Let's say that I'm editing component-1/component.tsx and now I want to edit component-1/index.ts. In the current version when I search "index.ts" I get (recently by name + random?) results with files named index.ts, instead, I would like to get component-1/index.ts, close to the first results.
Kind of "I want to open a file that it's close to the file that I'm editing".
In this case I'm editing Ruler.tsx and I want to edit ruler/factory.ts

What do you think?
What do you think?
I like but should really file a new issue - we don't often look at closed issues...
Most helpful comment
This will land in September behind a new setting:
"editor.suggest.localityBonus": true. With that sorting of suggestion depends on (in that order)The locality itself is computed by the enclosing scope, think of {}-blocks in c-style languages. See the attached screen shot below. The suggestion
wzzwins because it's inside the same scope, the outer scope haswareandwert, both have the same 'distance' and there the extension sort order (alphabetical) comes into play.