[Announce] autocomplete+ v2.0.0 Is Released


#1

After about a month of work, an entirely rewritten version of autocomplete+ (v2.0.0) has been released. This release addresses pretty much every qualm raised in What can we do to improve autocomplete? - with the exception of the quality of the suggestions provided by the built-in provider (FuzzyProvider).

Users should update to the latest version of atom and autocomplete-plus, and optionally install additional autocomplete Providers (note that some of these still need to be updated to the new provider API as of January 28th, 2015).

This rewrite was the result of a huge amount of effort by @park9140, @yongkangchen and myself, but it’s not the end of the road for improvement of autocomplete in Atom.

The next step to improve autocomplete in Atom is to ensure that each grammar (i.e. all the language-xxxx packages in the https://github.com/atom organization) has corresponding provider(s) that provide more specific suggestions than the built-in provider.

If you find yourself editing in a file and don’t like the suggestions you are getting, follow this line of reasoning:

  1. Look down to the grammar-selector status in the status bar and note the ‘grammar’ you see - it’ll be something like JavaScript, CoffeeScript, HTML, Plain Text, etc.
  2. Ask yourself “do I have an autocomplete-plus provider installed that caters specifically to this grammar?” If yes, file a defect in the corresponding repository; if no:

Notable providers that are currently compatible with the autocomplete-plus 2.0 API:

Additionally, language-csharp, omnisharp-atom has a pull request outstanding to update it to use autocomplete-plus and move away from the now defunct autocomplete-plus-async package.

One final note for the core team: one of the goals in this rewrite was to have your team consider autocomplete-plus as a replacement to core autocomplete. I’m fairly sure the transition of a package from “community” to “core” is unprecedented, so we’re looking for your guidance on this. We (@park9140, @yongkangchen and @joefitzgerald) are open to 1) a pull request or 2) a transfer in ownership of the repo. /cc @nathansobo @benogle @maxbrunsfeld @kevinsawicki @thedaniel and others I have missed.

Many thanks to @nathansobo and @maxbrunsfeld for the help in reviewing the PR https://github.com/atom-community/autocomplete-plus/pull/186 and in helping us evolve the service-hub API to support this new model of package <-> package integration.

And many many thanks to @park9140 and @yongkangchen for rescuing autocomplete-plus from the brink of oblivion.


Install autocomplete-plus providers - errr, how?
What can we do to improve autocomplete?
#2

Awesome work! Thank you for taking this on and shipping.

This request / suggestion / musing is based on a lot of ignorance about autocomplete and atom internals but here goes anyway…

I am sure that it would be optimal that each grammar defines an autocomplete provider per the API you have defined. But as a stop-gap and a massive improvement for vanilla autocompletion for atom out of the box (well, out of the box with autocomplete plus installed), would it be possible to create a generic language autocomplete provider that just sources the active grammar’s syntax file (language keywords?) for completions?

Again, I know nothing about atom’s internals, but it seems to me that that grammar must be readily available and exposed in a generic and fairly performant way, no? Otherwise atom would not be able to color stuff so prettily in the editor.

I think that if the active language’s keywords were the first thing to show up in the autocomplete list, I’d be very happy with atom autocomplete.


#3

I think if you add the autocomplete-snippets package to autocomplete-plus, you’ll be pretty happy. Most grammars come with a set of snippets for standard grammatic constructs such as loops and selection, function definition, etc. And even if there are gaps, snippets are something that are pretty easy to enhance yourself without waiting for the grammar maintainer to improve it for you.


#4

Thanks for the suggestion. I do have autocomplete-snippets and I am still pretty :sob:.

Snippets completion is great for a certain class of things, but there are a lot of places where the simple keywords of a language is the right thing.

Here is an example. I have language-css, language-less, and language-stylus all installed. language-css seems to have robust snippets that give me the following auto-completes (which are great):

But take a look at the less and stylus auto-completes (not so great):

In both cases (less and stylus), I know that all the same completions that are being offered in the css file are there as keywords for those grammars. I’m just imagining that it would be possible to leverage those grammars in a generic way for every language.


UPDATE: upon looking into the language-css and language-less packages it doesn’t appear that the completions that I posted above are coming from the snippets - at least not as defined by the language files (though I don’t know that the autocomplete-snippets package is not the provider).

Instead, in the settings/language-css.json file there are several stanzas labeled “completions” where I think the css completions are actually coming from. These “completions” stanzas are pretty much exactly what I had in mind when I was talking about the grammar’s “keywords”. There are no such stanzas in the language-less and language-stylus packages.


#5

Honestly, this is absolutely superb work! Well done guys and thank you so much. I’ve always disabled autocomplete before in Atom because it was horrendous (speed and functionality), but this seems to just NAIL it. Brilliant


#6

@pjv You’ll note that I caveated my statement:

This release addresses pretty much every qualm raised in What can we do to improve autocomplete?

With the following:

[…] with the exception of the quality of the suggestions provided by the built-in provider (FuzzyProvider)

This is what you take issue with, and for good reason. FuzzyProvider is dumb (it bases its suggestions on words in the current buffer or all open buffers), and consequently isn’t giving you the quality of suggestions you expect.

FuzzyProvider can and will be evolved to be better (see Can I Use Grammar To Determine A Word Regular Expression? for one vector).

You should also focus on what can be done on a grammar-by-grammar basis. For example: should a specific provider be created for language-css, language-less, and language-stylus? I’d argue: “yes”.

So we have two pathways forward, both of which should make your experience in each grammar better. Let’s focus on documenting your ideal features for both, and then we or the community can pitch in to address the desired functionality.


#7

We do already fetch editor completions - so this would be a great way for you to improve the quality of completions from FuzzyProvider without any changes to it. I.e. you would want to create issues or pull requests against language-xxx repos to add more completions for the grammars you are interested in. Many thanks if you do take this route, as it will improve the experience for everyone!


#8

I tried this a couple minutes ago with language-less but didn’t get it working on the first pass. I’ll keep at it and provide PRs for those grammars I use where I can relatively easily copy a good set of completions somewhere as in this case (less being essentially the same as css).

However… I still have the idea hovering, since nobody has given a reason to debunk it, that it should be possible to write a generic syntax/grammar completion provider based on any (every) grammar’s list of keywords. Having that would obviate the need to tweak each grammar as we are discussing here. Instead of (or in addition to) looking for the “editor completions” (or in the case of grammars that do not provide any), could you not “fetch” a grammar’s list of keywords somehow? Atom has to know what they are to colorize the editor, right?

Sorry if I am beating a dead horse here.


#9

If you take a look at the actual grammar descriptions, they don’t have this list of keywords you’re talking about. They have regular expressions. Regular expressions are great for taking a look at a string of text and deciding if it matches … but they are notoriously bad at generating the set of all possible matches. (They’re kind of like one-way functions in that sense.)

Sure, you might be able to take a look (as a human) at these patterns and extract the things that are useful keywords out of them:

But it would be much tougher to make something useful out of this rule (in an automated fashion):

Basically, if there was an easy win … I trust that @joefitzgerald, @yongkangchen, @park9140 and the many, many others that contributed to this effort would have taken it.


#10

Got it. Thanks @leedohm for the thorough explanation.


#11

@leedohm is it possible to cross-post this in #features?


#12

No, Discourse doesn’t have such a feature. I could change it to the features category … but you could do that too :grinning:


#13

I haven’t followed the whole thread in details, so I’ll catch it up later. but I have seen two things I think is missing:

  1. A v1 to v2 conversion tutorial. So that providers maintainers can easly grasp what they need to change.
  2. A provider package generator. I’ve implemented one for minimap plugins if you need an example.

BTW, I don’t know if someone is already dedicated to this, but I think I’ll try to write a CSS provider (for both properties and values) after having stabilized and advanced my table edit package, and releasing minimap v4, and updates its plugins, ^^.


#14

We made the determination that there are so few v1 providers and we’re in direct contact with most of the authors of widely used ones that we would just update the providers ourselves, or directly assist provider authors in the conversion. Said another way, it’s easier for us to just help you or anyone else who has a v1 provider make the conversion. Head to Gitter for interactive assistance: https://gitter.im/atom-community/autocomplete-plus

This is a great idea.

This is also awesome! I am going to update https://github.com/atom-community/autocomplete-plus/wiki/Autocomplete-Providers to include a table and highlight efforts to add provider(s) for grammars where there are none today. Do you have a candidate name for the package? Also, you’re welcome to locate it at https://github.com/atom-community if you would like, or in the usual location (https://github.com/abe33). Just let me know on the former - I think I’ve already tried to add you as an owner of atom-community, but you haven’t accepted the invite.


#15

It’s now done, I had forgotten about it :).

As for you questions, I think I’ll locate the repo in atom-community, and as for the package name I’m open to suggestions, if we can make most providers use the same convention it’ll be simpler for everyone.