Modify Provider / Suggestion API To Be Asynchronous about autocomplete-plus HOT 14 CLOSED

Reading through the runAutocompletion source, the activities of:

• Notifying providers of the need to provide suggestions
• Aggregating suggestions
• Displaying suggestions

... are conflated. If we were to decouple the three, and provide events to drive each activity, this could be made asynchronous.

  runAutocompletion: =>
    if @active
      @detach()
      @list.empty()
      @editorView.focus()

    # Iterate over all providers, ask them to build word lists
    suggestions = []
    for provider in @providers.slice().reverse()
      providerSuggestions = provider.buildSuggestions()
      continue unless providerSuggestions?.length

      if provider.exclusive
        suggestions = providerSuggestions
        break
      else
        suggestions = suggestions.concat providerSuggestions

    # No suggestions? Don't autocomplete!
    return unless suggestions.length

    # Now we're ready - display the suggestions
    @setItems suggestions
    @editorView.appendToLinesView this
    @setPosition()

    @setActive()

from autocomplete-plus.

I totally understand that, but modifying it to become asynchronous will cause other issues:

• We'd have to re-render the suggestions every time a provider broadcasts suggestions
• We could not have exclusive providers anymore (or only with weird issues, e.g. if Provider A is not exclusive and has suggestions, but Provider B is exclusive and provides suggestions with a 1 second delay, then we would first see A's suggestions, but after one second they would disappear and be replaced with B's suggestions)

from autocomplete-plus.

You could actually address both issues:

• (If multiple providers exist) Trigger events on all providers, and expect that you will collect an event from each for a given cursor position – even if that includes zero suggestions
• (If an exclusive provider exists) Trigger events only on the exclusive provider
• Pass the current EditorView and position in the events you trigger on providers, and require that suggestions are emitted with that same position
• Collect events while the cursor is currently in the same position
• Drop events when the editor's current position is no longer a match for the suggestion's position

https://atom.io/docs/api/v0.85.0/api/classes/Editor.html#getCursorBufferPosition-instance

There's nothing wrong with re-rendering the suggestions view every time a provider broadcasts suggestions; but you could suppress it by simply collecting suggestions until all providers have returned, and then emitting an event to render the suggestions, which the rendering method would be bound to.

from autocomplete-plus.

Has anyone done any work on this issue recently? I have a case in my typescript tools implementation where the completions don't come back instantly because they are requested from an external process.

Additionally, there are two stages of info I want to show in the popup. First the word completions, these come back quickly(but still async). Second a slower process loads up the jsdoc info for the completion. Ideally the completion data set could be ammended with more information after the fact.

If no one is currently working on this I could throw out a pull request.

from autocomplete-plus.

@park9140 I've not made further progress on my work in this area - if you want to take a stab at it, please feel free. Regarding your desires (and mine for this), consider the following:

• Dispatch of events to registered provider(s) should occur continuously while the autocomplete trigger occurs
• Display of suggestions should be scoped to the current buffer position plus some other random identifier at the time of event dispatch
• The provider base class should use emissary and be a subscriber and an emitter
• The autocomplete-plus plugin should register an @on handler for each provider registered to it to ingest suggestions via an event in the provider API
• A sliding window should cause the display of ingested suggestions to occur while the buffer position and random identifier (which should change with each buffer change) remain the same; when they do not match, the suggestions should be discarded; optionally, when they do not match, the providers will be notified with a cancel event for the cancelled buffer position and identifier
• While the buffer position remains unchanged, the view should continuously update while suggestions are found

Hope that makes sense?

from autocomplete-plus.

Just hit this issue while trying to implement python autocomplete (https://github.com/kbrownlees/autocomplete-python-jedi). Has anyone done enough to put a dev commit somewhere? Also any more info on the status of the autocomplete / autocomplete-plus merge?

from autocomplete-plus.

I have put some work into options but have not settled on an implementation. As it stands I'm thinking that the current methodology is a lost cause and needs a ground up rewrite to properly support autocomplete. I have some work done of a new more complete mvc style breakout of the base autocomplete library in my fork right now if you are interested. It is by no means "complete" but it gives a bit of an idea as to the direction I am trying. The goal of the rewrite is to break out the original implementation and then in a future pull break out a plugin architecture.

Still unsure what the plugin architecture should look like at the moment. I'm working on the core AtomLinter and it's architecture is also quite lacking. I'm thinking we need to put some work into atom core package manager to support plugins having plugin dependencies, at the moment.

from autocomplete-plus.

I now have a very solid opinion on what this should look like as an API and also the way that autocomplete-plus should be calling out to providers.

I – like you, @park9140 – think that this is a non-trivial undertaking and essentially requires much of the way autocomplete-plus works to be rewritten. But I think this should occur as an evolutionary step. I am currently refactoring much of (go-plus)[https://github.com/joefitzgerald/go-plus] and once that is complete later this week I will have some cycles to spend on this work.

from autocomplete-plus.

👍

from autocomplete-plus.

How about this:

https://github.com/HaxeIDE/atom-autocomplete-plus-async/blob/master/lib/autocomplete-view.coffee#L147

I switched to callbacks for everything.
Does works for me.

from autocomplete-plus.

@saschagehlich would you be interested in pull request? Currently in my fork I switched to callbacks. But I can make an async option for Provider.

from autocomplete-plus.

Now that ES6 Promise is supported in HEAD, it might be a good basis for the async API.

from autocomplete-plus.

See also: atom/atom#4364

from autocomplete-plus.

This will be fixed in #184.

from autocomplete-plus.