What can we do to improve autocomplete?


#1

I’ve used several code editors with some form of autocomplete. Here is a typical behavior (in Sublime):

Here’s what I expect (and get):

  1. suggests the tag I am typing
  2. offers relevant attributes
  3. adds the chose attribute, with quotes and insertion point ready for me to type the class

Now, try this in Atom:

  1. All that’s suggested is useless words from the document
  2. After I ignore this, and type P, I get more nonsense but I see “class”
  3. so it types only the word

Seriously? Is this the best that can be done?

I wind up turning off autocomplete altogether and, coupled with Emmet never working in Atom, makes me have to type a lot more that I have to in my other editors.

Can this be fixed or augmented?


[Announce] autocomplete+ v2.0.0 Is Released
Jsdoc/ any doc during autocomplete
Atom editor autocomplete isn't "smart" (intellisense). any fixes?
Actual method, functions and classes display hinting, auto-complete and support
Is it possible to get PHP function document?
[Announce] autocomplete+ v2.0.0 Is Released
Autocomplete Plus | confusing behavior after confirm
Finishing items
#2

I understand that you’re frustrated that Atom isn’t working the way you expect it to. On the other hand, neither the people here nor the Atom team are the cause of your frustrations. You’ll find that people are eager to help if you work with them instead of berating them.

So, here are a couple of suggestions on how to turn this topic around:

  1. Change the title to something more constructive. For example: “What can we do to improve autocomplete?”
  2. Instead of stating problems and dumping them in the laps of others, offer solutions. Perhaps you have some suggestions for implementations that are better than the current ones? Perhaps you can do some experimentation and submit a pull request? Perhaps you can work with @saschagehlich, @joefitzgerald or the others contributing to the autocomplete-plus package?
  3. You also might want to read the topic Topics that start with “Why” for discussion around the way your post could be perceived by others.

Thanks.


#3

Sorry. I was just totally frustrated at this point. i have been posting more suggestion-oriented posts, and have tried to find workarounds. I have tried a few packages too, but nothing seems to give me the simple, direct hinting I outlined.

It just came to sort of a head today as it seems like such a basic thing, to provide hints for a given language (especially html). Oh, well.


#4

The autocomplete-plus package has been officially abandoned by @saschagehlich, and I do not have a desire to maintain it.

This presents an interesting predicament:

  • I agree with you @smlombardi that the autocomplete in Sublime is much better than the autocomplete in Atom.
  • Autocomplete is so fundamental to an editor/IDE (Atom’s really stuck in the middle there) that it benefits greatly from focus from the core team.
  • I really don’t think Atom can go to 1.0 with the current state of Autocomplete, but that’s purely a personal opinion.
  • Autocomplete has such a wide scope that I’m honestly scared to try to fix the problem myself; I don’t want to be responsible for maintaining something so core to the editor - there’s not enough time in a day for a single contributor to take that on.
  • As a package author of go-plus, the lack of great autocomplete is actually stopping users of other tools (e.g. Sublime + GoSublime, LiteIDE, IntelliJ + GoIDE, even vim/emacs) from migrating to use Atom. There are numerous examples of this on Reddit, Hacker News, and other forums. So I desperately want to be able to quickly integrate with an Autocomplete API to add gocode support to my package, but I cannot then extend that to (re)writing all of Atom’s autocomplete - it’s just not a reasonable proposition.
  • atom-ctags is entirely dependent on autocomplete-plus, as are many other packages - if pluggable autocomplete isn’t addressed systematically, a whole category of packages are going to fall into a state of disrepair (/cc @yongkangchen).

It is my opinion that fixing / enhancing autocomplete has to be something led by the core team, with community contributions on the periphery (i.e. by building awesome autocomplete providers, once an API is in the core!).

/cc @kevinsawicki @nathansobo @ProbablyCorey


#5

I agree that Sublime’s text editor has much better autocompletion. A simple method that would be pretty effective is a simple Tokenizer that feeds tokens into either a Trie or Lookup-Table. I’ve found that the lookup table is more effective because you can insert multiple variations into the table and have a ‘fuzzy’ style matching criteria at very little cost of memory. One thing that I would like Atom or Sublime to do that it currently doesn’t is to do either a directory or open-files based matching. Currently, Sublime only matches tokens from within the file that you are currently editing. I have code that implements both Tries and Lookup tables in Javascript that I could contribute to the project if someone could integrate it - I’m not too familiar with the Atom code base.


#6

You’ve done a good job of outlining the problem, @joefitzgerald. And the contents of this PR outline an approach to a provider-based autocomplete solution:

So rather than trying to revamp autocomplete all at once, what are some small steps that can be taken to move Atom’s built-in autocomplete package in the direction people want it to go?


#7

Also, I wanted to toss my own idea into the ring. I haven’t looked at the autocomplete-plus package, so I don’t know if this is how it works. But suggestions providers should rank their individual suggestions from 0.0 to 1.0 so that the autocomplete package can simply order them from highest to lowest when showing the options (and perhaps have some tie-breaker or usage-frequency logic). This is how search engines rank their search results to decide what ends up in which order. (And really, that’s what autocomplete is at its core … a search engine to guess what you want to type next.)

For example, in the GIF above @smlombardi types <p, so the HTML autocomplete provider might return something like:

  • <p%1>%0 — 1.0
  • < pre%1>%0 — 0.9
  • <param%1>%0 — 0.3
  • <person%1>%0 — 0.1
  • <plaintext%1>%0 — 0.1

But maybe the Snippet provider could return something like:

  • <p class="%1">%0 — 0.95

So they would get sorted together in a natural order. Adding usage-based tweaks is also pretty simple, just add a 0.001 or something per time used. Maybe each suggestion should include a UUID so that usage can be easily tracked by the autocomplete package.

Just some thoughts.


#8

So rather than trying to revamp autocomplete all at once, what are some small steps that can be taken to move Atom’s built-in autocomplete package in the direction people want it to go?

That’s kind of my point. I’ve tried to take small steps, but the current implementation requires a complete rewrite.

  • The view needs to be rewritten to update continuously as asynchronous suggestions roll in
  • The view needs to be enhanced to add additional metadata (like the type [int, string, etc] for a suggestion)
  • There needs to be a provider / suggestion API introduced
  • The fuzzy provider needs to be extracted from the view and enhanced
  • There needs to be proper separation of Model and View, like the rest of Atom’s core is doing
  • The entire package needs to be updated to use new approaches for Views (no space-pen), the Atom API (deprecations galore), etc.

In essence, there’s more work to incrementally improve this vs. rewrite it. Ironically, the fact that the autocomplete package does not have an API makes this much easier than doing it in the autocomplete-plus repo, because there you have to manage the impact of change on all the dependent packages.

Change here should start with the deliberate design and specification of an (async) autocomplete API, the implementation of that API, followed by a UX design for how autocomplete should work from a user’s perspective. A user’s satisfaction with an editor is sometimes inextricably linked with their experience with autocomplete. A great experience with autocomplete makes them tremendously happy. A horrible experience with autocomplete makes them go back to where they came from.


#9

FWIW, Joe has articulated the problem quite well. The lack of a functioning autocomplete system greatly diminishes Atom’s usefulness as a code editor, at least for HTML and similar tag-based languages.

This, combined with the problems I have had getting Emmet to work properly in Atom, means to work on HTML in Atom requires far more typing than Sublime, Brackets, Coda, Espresso, etc.

I think good points are being discussed here, and I am curious to see what comes out of it all. Thanks.


#10

To be honest though, this is always true of any significant software system.

I just feel that completely rewriting it was attempted in autocomplete-plus and getting that functionality handed back to the Atom team didn’t work for whatever reason. So maybe a different approach needs to be attempted?

We all agree that autocomplete in Atom needs to be improved. We’re just discussing options for how to get there from here :grinning:


#11

I happen to be retired and if I say so myself I am up to the task. Of course support from others would help. If the API is good enough that support can be in the form of add-ons.

@Lee-dohm and I have discussed this. We think that if Lee and I work together, and by listening to people in the forum, the core team doesn’t have to orchestrate it. This is open-source after all.

I agree with Lee on this. Incremental improvement has a number of advantages. A big one is the agile methodology which I believe in even though it is out-of-favor in some quarters now. Also, who’s to say that when we are done it won’t be 100% different code? (grin)

Right now Lee and I would just explore the options in more depth with the goal of actually changing things soon.


#12

@Lee-dohm and I have discussed this. We think that if Lee and I work together, and by listening to people in the forum, the core team doesn’t have to orchestrate it. This is open-source after all.

@mark_hahn I really do appreciate you and @leedohm’s willingness to pitch in (!!).

I suppose what I hope for is that the core team really prioritizes great autocomplete for 1.0. While the core team “doesn’t have to orchestrate it” (my emphasis added), I think it would be beneficial for the entire package ecosystem if they did orchestrate it.

I’m interested in thoughts from @kevinsawicki, @nathansobo, and @ProbablyCorey on this, because it’ll give us all some direction:

  • The community should assume complete control of autocomplete
  • The core team will remain committed to the autocomplete package, and no significant changes will occur prior to 1.0
  • The core team will remain committed to the autocomplete package, and significant changes will occur prior to 1.0
    • These are the areas the core team will focus on: <a>, <b>, <c>
    • These are the areas the community will focus on: <x>, <y>, <z>

So - I’m more fishing for an opinion and insight on the product backlog (and prioritization within it) as a first step, so that we can take concrete actions based on what we hear.

As an aside, @leedohm, can you add the #packages tag to this topic, and move it out of support?


#13

I don’t see it on the roadmap so I assume not this one.

Edit.
Well it looks they want to address the performance first. It’s on their todo list for v1.0 [1]

[1] https://github.com/atom/atom/issues/3684


#14

@dsandstrom Yeah, I’m trying to make a case for the prioritization of this :wink:. There’s a subtext to what I’m saying:

Hey! Can we please get this prioritized? Pretty please?

  • Me

#15

I was just thinking about this the other day. The current state of this is undesirable, the core team needs to focus on this prior to 1.0.


#16

It’s may be naive of me, but can’t we continue the enhancements on autocomplete-plus in a way that allow to replace the core autocomplete package at some point? AFAIK the former was initially a fork of the latter, so it’s not like we have to start from scratch again.

@mark_hahn & @leedohm: If you need a helping hand, I’m here :slight_smile:


#17

@abe, most things are possible :smiley:. But as someone who was working on that, I’m trying to advise that it is more work than it’s worth to pursue that approach.

A key issue is the existing autocomplete-plus API is synchronous and so on order to change it (which is required), you need to coordinate the change with many other packages to avoid breaking them.

Then there is the pile of 50+ issues, the somewhat poor performance, the need to still modernize the way it interacts with Atom (the API has changed significantly since it was last modified). I’ve spent quite a bit of time at least making the autocomplete-plus tests sane, but I haven’t run them in a while either.

@saschagehlich actually did a good job of starting to move logic out of AutocompleteView, but there’s still a very entangled mess in there that is a heritage of forking autocomplete.

And the view needs a rewrite to separate model and view and also just look great. It’s saddled by most of the same issues that affect the autocomplete UX.

So yeah, it’s possible to do what you described (and we discussed this and got agreement with @kevinsawicki that they would accept that contribution). But what’s possible isn’t always the wisest path forward.

I’m waiting on a response from the core team until I am able to personally decide what the right / wisest course of action is.


#18

Isn’t it possible to support both (sync and async) with async providers as opt-in so that existing packages doesn’t break?


#19

The API should switch to be async, to be more performant (although I don’t have numbers to stand behind). Particularly if the default autocomplete has autocomplete on keystroke enabled by default (which it probably should).

Again, I think any effort here starts with good API design that makes it into the core API, and ideally is unencumbered by the autocomplete-plus API.


#20

Ultimately, we want autocomplete to be owned by the core team. There is a lot on the roadmap right now, and we’re hesitant to make any promises right this minute because we might not be able to keep them.

We’re thinking about this. I agree with all the sentiments about autocomplete. I want this to be better too. Like OP, the results are often not what I want, and I dont use autocomplete-plus because it pops up too much with too little utility.

Apologies for the pain this is causing.