Autocomplete + machine learning?


Question: Could Autocomplete suggestions be based on how often you type something? Maybe through machine learning?

Problem: Currently, autocomplete suggests what gets provided by language packages. For example if I type margin: in a .less file, it suggests some of the possible values that are valid.


But often it will be a number, like 10px. Or a variable like @spacing. It would be great if autocomplete would suggest that.

Workaround: As a workaround, I started to create snippets that include variables. Autocomplete picks them up and shows them at the top. This lets me just type ma + enter and it completes to margin: @spacing;, which is great. But it’s pretty tedious to maintain this manually.


Possible Solution?: Would it be possible to use machine learning to have autocomplete show these more “personal” suggestions? Like after entering margin: @spacing; many many times, the neural network (or however it’s called) should learn and offer that as the top suggestion.

There are efforts that try to solve this problem, but they are based on everyone’s code. This might work in a lot of cases, but because things like variables wary between projects/users, having suggestions based on what you type most, might result in even better results? :thinking: It might take a bit longer to “train the machine”, but the longer you do, the better the suggestions become. Or for a head-start your entire commit history on GitHub could be used?



I don’t know how much of this needs to be machine learning (plus I don’t like the idea of suggestions being rearranged unpredictably).

Could Autocomplete suggestions be based on how often you type something?

The default provider already does this for everything in the file, so maybe like how that does it but syntax aware? You also shouldn’t need a neural network to count variable use frequency. Even a “dumb” provider would also be able to use the context of the cursor to fine tune the options.

But often it will be a number, like 10px . Or a variable like @spacing . It would be great if autocomplete would suggest that.

A full provider package would be able to generate the completions dynamically, presumably adding in variables available in that scope. It could do numbers too, but I don’t know how useful number completion would be (though I don’t use CSS as much as you).


There are just so many variants (packages etc) now available in Atom that sometimes it is easier to roll an automation script to run outside the Atom framework.
This automation script creates a popup window containing a fixed list of attributes to select from, copies selected text to clipboard, pastes text into Atom buffer. No autocompletion takes place.


If the preference is to keep this inside Atom framework then it seems (from searching around) that fuzzaldrin-plus is the matching engine to explore.


Yeah, that might feel jarring. I think in the beginning, it would be unpredictable… but after using it for a while, the order should stabilize? Well, until you start to change variable names for example. Then for a while both variable names would be suggested.

Maybe just add a count for every line that gets typed. Then use that as an additional suggestion provider?

It might be that the Less language package would need to be improved. Because even though the variables a linked at the top of the file, it seems Autocomplete still doesn’t import them. Maybe because of performance reasons? There could be tons of nested imports.

Thanks… :+1: I’ll give fuzzaldrin-plus a try to see if suggestions are improved. Edit: Ok, I think you meant to use fuzzaldrin-plus as a “matching” library for Autocomplete-plus? Not sure how to do that. I thought fuzzaldrin-plus is an Atom package that can be installed. :joy:


Snippets are statically defined, and are likely what you’re refering to. It seems the general convention is to separate syntax highlighting (language-*) from language features like autocomplete (autocomplete-*). Personally, I don’t even like how snippets are defined by the language-* package. Fortunately they can be disabled now.

A proper Less autocompleter would be called something like autocomplete-less, and would be able to import these variables (or at least be able to read files and execute arbitrary code to generate the sugggestions; it would need more help to know that “this file is being used in the context of an Atom style”).

If you actually are using a dedicated Less autocomplete provider, then the limitation is caused by the provider itself, not by restrictions placed on it. But assuming this list is up to date, one hasn’t been made yet.

1 Like

I found this boilerplate which might be used to build a custom autocomplete package. See the example URL in lib/advanced-provider.js … perhaps this could be expanded to be an adaptive API.


The wiki has instructions on how to make a provider, the difficult part is parsing and understanding Less enough to know where to get the suggestions, what to show, etc.