8000 Autocomplete Next · Issue #4364 · atom/atom · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Mar 3, 2023. It is now read-only.

Autocomplete Next #4364

Closed
benogle opened this issue Dec 2, 2014 · 45 comments · Fixed by #6710
Closed

Autocomplete Next #4364

benogle opened this issue Dec 2, 2014 · 45 comments · Fixed by #6710
Labels
atom enhancement

Comments

@benogle
Copy link
Contributor
benogle commented Dec 2, 2014

We're not quite ready to tackle a new autocomplete yet, but I wanted to start the conversation as there are several folks interested in working on autocomplete: @mark-hahn, @lee-dohm, @joefitzgerald, @abe33.

Once we finish with API related things, I was planning on:

  • Looking at autocomplete-plus code
  • Checking out all of the existing providers out there.
    • How many are out there? What are the popular ones?
  • Looking at code @mark-hahn and @lee-dohm produced recently
  • Looking at other editors. How do they do it? Do they have APIs?
  • Are there autocomplete daemons out there we can use (e.g. https://github.com/nsf/gocode for Go)

Then I would come up with a plan of attack for the new version. In my mind, we have a couple options:

  • Extend autocomplete with an API
  • Take over autocomplete-plus with some modifications and API changes
  • Write something completely new

I am not sure what the best way forward is right now. I do feel, though, that the hard part is not the UI that pops up the completion box, it's having great language support, and a nice API for adding completions.

It would be great if you guys could help me / us work through the research phase. Off the top of my head, I'm thinking these would be a big help:

  • Your opinions and suggestions for the provider API.
  • Your architectural suggestions (I know @mark-hahn wrote one recently)
  • Comments explaining the pitfalls and your frustrations of the current autocomplete-plus API. Maybe suggestions on improvements.
  • Links to autocomplete providers for languages (either generic providers or for other editors)
  • Explanations / links to APIs in other editors
  • General autocomplete API related frustrations and desires

Resources

Providers

Autocomplete+ providers

https://github.com/atom-community/autocomplete-plus/wiki/Autocomplete-Providers
@benogle benogle self-assigned this Dec 2, 2014
This was referenced Dec 2, 2014
Closed
Closed
@park9140
Copy link
park9140 commented Dec 2, 2014

Just to add some research, I have been using HaxeIDE/atom-autocomplete-plus-async in my park9140/atom-typescript-tools. It is a fork of autocomplete-plus with async support, and seems to work well.

@edubkendo
Copy link

I'm the author of https://atom.io/packages/rsense and https://atom.io/packages/racer, and I've also implemented rsense completions for sublime text and worked on it for emacs and vim. I have found the autocomplete plus provider api to be quite nice to work with, except for the fact that it is not async. This has required some hackery and global state manipulation , and means that it occasionally acts buggy since fetching completions from external sources is essentially an asynchronous act.

Sublime Text has an ok completions API, though its thoroughly undocumented or at least was when I last checked. The nice thing there is that the API is built into the editor and you don't have to tell the user to install some other thing besides your plugin.

Emacs and Vim have both been more difficult.

@joefitzgerald
Copy link
Contributor

omnisharp-atom also makes use of autocomplete-plus-async.

@nathansobo has an interesting PR including some modernization of autocomplete, which needs to be upstreamed to autocomplete-plus: atom-archive/autocomplete#54

It seems like a prudent short-term course of action might be to:

  1. Upstream Remove usage of deprecated APIs atom-archive/autocomplete#54 to autocomplete-plus
  2. Evolve the autocomplete-plus provider API to be async, preserving the ability for providers to stay synchronous if they choose (while unwittingly still being async) - the easiest way to do this initially might be via callbacks
  3. Upstream autocomplete-plus to autocomplete
  4. End-of-life autocomplete-plus, autocomplete-plus-async and derivatives

This then presents an opportunity for the autocomplete package to take one of two paths:

  1. Progressively evolve the package
  2. Start fresh and provide a migration for providers to a redesigned version

There has been some discussion of modernization of the AutocompleteView, to HTMLElement or React. @abe33 is investigating further, at the direction of @nathansobo.

@abe33
Copy link
Contributor
abe33 commented Dec 2, 2014

Evolve the autocomplete-plus provider API to be async, preserving the ability for providers to stay synchronous if they choose (while unwittingly still being async) - the easiest way to do this initially might be via callbacks

I would advocate for a promise-based API, the provider just have to return a promise to use the async API, if it want to stay synchronous, it just have to return an array instead. No changes needed for providers that already works in a synchronous fashion.

I do feel, though, that the hard part is not the UI that pops up the completion box, it's having great language support, and a nice API for adding completions.

Agreed, but there's some use cases that should be considered early, like icons in the results (for statically typed languages IDE it's rather common to have the type and the visibility of a property/method as an icon), or for displaying colors as I did in the project-palette-finder.

Your opinions and suggestions for the provider API.

I would like to see an option to limit the scope of a provider to a specific list of scopes. This would lessen the burden on providers authors and limit the performance hit of having all the providers running at the same time. A provider could just provides a default list (empty lists matches all scopes), that could be modified later by the user from a setting (maybe a dynamically created setting for each registered providers) so that every providers can be managed from a single page.

Also I would like to see a unified way to compute suggestion scores, with fuzzy filtering being part of the basic autocomplete package (as a helper method so that provider doesn't have to implement that on their own).

Links to autocomplete providers for languages (either generic providers or for other editors)

project-palette-finder provider

@benogle
Copy link
Contributor Author
benogle commented Dec 2, 2014

Thanks to everyone so far. Keep them coming.

It seems like a prudent short-term course of action might be to ... Evolve the autocomplete-plus provider API to be async...

I'd rather think long term though. I'm not sure if updating autocomplete-plus is the best course of action. I would hate to change the API, get people to update their providers, then do something for the long term like rewrite autocomplete, and require people to update or recreate their providers again.

@mark-hahn
Copy link
Contributor

Evolve the autocomplete-plus provider API to be async...

I don't see how this solves anything. If a provider is synchronous and it
takes over a thread the callbacks help nothing. It has to be in a separate
process.

On Tue, Dec 2, 2014 at 11:18 AM, Ben Ogle notifications@github.com wrote:

Thanks to everyone so far. Keep them coming.

It seems like a prudent short-term course of action might be to ... Evolve
the autocomplete-plus provider API to be async...

I'd rather think long term though. I'm not sure if updating
autocomplete-plus is the best course of action. I would hate to change the
API, get people to update their providers, then do something for the long
term like rewrite autocomplete, and require people to update or recreate
their providers again.

—
Reply to this email directly or view it on GitHub
#4364 (comment).

@joefitzgerald
Copy link
Contributor

@mark-hahn it's a matter of progressive elaboration. The API needs to support asynchronous suggestions. That does solve problems associated with external / daemon-based processes that provide suggestions (e.g. gocode, OmniSharp, etc.).

That doesn't preclude further enhancing the way providers are called to move them off to a separate process. That wouldn't / shouldn't change the API itself.

@edubkendo
Copy link

I don't see how this solves anything. If a provider is synchronous and it
takes over a thread the callbacks help nothing. It has to be in a separate
process.

@mark-hahn

Because many providers work by calling out to a tool that runs in an external process, gocode, rsense and racer are 3 examples that work like this. The API's for spawning or executing those processes are async API's. Whereas autocomplete-plus's provider API is synchronous, and because of the way it works, leaves you doing hacky things like setting completions on a class var and hoping you don't hit race conditions (which , of course, you do). It's an entirely different problem from the one where a process blocks the thread.

@park9140
Copy link
park9140 commented Dec 2, 2014

I have been working with the autocomplete-plus-async package and one of the primary issues that seems to pop up with async is that we get race conditions between the debounced change event, and the request for autocomplete. This presents as showing and working with an autocomplete list that is in the process of being replaced, and depending on how fast you are tab completing you can end up selecting a completion that is not what you expect.

I also would like to spend some on the plugin architecture. Many of us have put a lot of work into plugin architecture for the AtomLinter project, and we seem to have a pretty solid methodology there. There is significant amount of registration and management of the related dependent plugins that could be rolled into a common library for use in all of these type of projects.

@joefitzgerald
Copy link
Contributor

I'd rather think long term though. I'm not sure if updating autocomplete-plus is the best course of action.

I'm not saying don't think long term 😄. Just simply suggesting that in the short term there are some achievable quick wins that would move the ball forward while giving you the option of further evolving from the base autocomplete package if / when the packages are consolidated.

I would hate to change the API, get people to update their providers, then do something for the long term like rewrite autocomplete, and require people to update or recreate their providers again.

I think implicit in the suggestions I'm making is that existing providers would not have to make changes in the short term until the long term API changes occur. But we can switch to async while being backwards compatible - just requires that we enhance the provider to include a function that is async (handleSuggestionRequest? buildSuggestionsAsync?) that calls the synchronous method (buildSuggestions by default, but which can be overridden by async providers.

When I first started contributing to the discuss thread, I was of the opinion we should throw everything away and start fresh. I've since evolved my thinking to prefer enhancing autocomplete-plus, upstreaming autocomplete-plus > autocomplete, and then enhancing autocomplete (with an optional complete rewrite with temporary support for the current autocomplete-plus API).

The reasons why I changed my opinion include:

  • This provides a clear migration path for existing autocomplete-plus providers, and might achieve consolidation of the autocomplete package ecosystem relatively quickly
  • This moves the issue burden and maintenance to a single repo in the interim, while the long term solution is worked on
  • This potentially removes conflicts between the various autocomplete derivatives, lowering overall autocomplete churn and the perception that it is fragmented
  • This allows gocode functionality in my package to move more quickly to depend on a core package and consequently potentially benefit from changes to the core that are orthogonal (but related) - e.g. the rewrite of select-list-view to use HTMLElement - when these changes occur in the core, packages on the periphery like autocomplete-plus are not included in the migration, as they don't fail your tests 😉

@mehcode
Copy link
Contributor
mehcode commented Dec 3, 2014

Code-completion is so much more than auto-completion. It can be achieved with auto-completion but we need to make sure that auto-completion is flexible enough.

Some thoughts:

  • Context — If I type self. (python) I should (using jedi or something similar as the provider) be given only the attributes on self. If I am typing inside a method and I start typing appl and there is a local variable applesauce but a global variable apple the local variable should (in my opinion) have a higher weight / confidence in the suggestion box.
  • Meta — Just the name of the symbol is not enough. When I type print( I should get a pop-up under my cursor explaining just what print is (depends on the provider, using python again it should be doc comments). Going even further, when I type format("hello",, the , should trigger some event to the provider so it could update the documentation to show the parameter that I'm on position-ally.
  • Defer — Providers should be able to defer to other providers. Take C++ for example this time. If I type #include < I should now be auto-completing a path with the system include directories weighed higher and if I type #include " I should be auto-completing a path with the current directories weighed higher.

In the immediate future just a solid name / symbol completion would be awesome but the above are some next-level thoughts following the title of this issue.

@joefitzgerald
Copy link
Contributor

@mehcode Regarding Context, there are multiple implementations of autocomplete-plus (or derivatives) providers which do exactly as you describe.

In the case of my package (go-plus), I use a daemon called gocode which understands the context of the current cursor position and provides suggestions that are contextually correct.

Context is language specific, and so determining context is deemed to be in the realm of the autocomplete Provider rather than the core package itself. Some Providers may be bundled with the core package which blurs the lines somewhat.

I think your Meta item is also language-specific and up to each provider. It does raise a question though: "what should a suggestion look like?". Right now, it's fairly sparse, but could be richer.

Defer is interesting, in so far as the example you provide (filesystem paths) could be a centrally provided suggestion, but also could reside in the realm of the provider.

@mehcode
Copy link
Contributor
mehcode commented Dec 3, 2014

@joefitzgerald I know its fairly language / provider specific. I'm just trying to get people thinking about the end-goal rather than an API. Its easier to design the API when we can all envision the end-goal.
8000

@park9140 park9140 mentioned this issue Dec 9, 2014
Closed
@park9140
Copy link
park9140 commented Dec 9, 2014

@mehcode, I like the defer suggestion, however, It would be nice if we had a more integrated way of determining where the deferral happens. I've been using atom scopes to detect when to do certain actions like displaying parameter completions for functions. Could we perhaps have the api, for what provider to use, and when to activate, be dependent on the scope of the context.

So ideally the include case in the c++ language would have something like meta.path.file as it's one of it's scopes. You could write the file completion provider so it engages on the meta.path.file scope only, and since that would be more specific than say the source.cpp scope that would provide the hint for the autocomplete provider's results to be first.

@yongkangchen
Copy link

@benogle I add a wiki page: https://github.com/atom-community/autocomplete-plus/wiki/Suggestion-Provider-List

@joefitzgerald
Copy link
Contributor

@benogle We've (@yongkangchen, @park9140) been making significant changes to autocomplete-plus to modernize it in-line with the changes to autocomplete. Updates:

  • We are almost done with a refactor to switch AutocompleteView to HTMLElement (@park9140)
  • We will then introduce AutocompleteManager, shifting much of the responsibility from AutocompleteView to AutocompleteManager (e.g. managing providers)
  • We will be updating the provider API further to leverage scopes instead of editor registration, allowing us to potentially move away from - this will be a breaking change so will be available in parallel to the existing API until providers have been migrated
  • We have moved autocomplete-snippets and autocomplete-paths into the atom-community organization, and updated them - but are waiting on database change(s): Cannot publish: Creating new version failed: Git tag not found apm#218 (fixes: Uncaught Error: ENOENT, no such file or directory '/User Guides And Information' #4470)
  • Omnisharp-Atom seems like it will jump on board once an async buildSuggestions function exists

At that point, I think I will create a PR to upstream autocomplete-plus to autocomplete, and plan the deprecation of autocomplete-plus.

@benogle can you provide an update from your end?

@benogle
Copy link
Contributor Author
benogle commented Dec 15, 2014

At that point, I think I will create a PR to upstream autocomplete-plus to autocomplete, and plan the deprecation of autocomplete-plus.

I want to be clear that I am not sure this is the best approach.

We have not started looking into this in any depth yet. We will likely not get to it until Jan.

@joefitzgerald
Copy link
Contributor

We will likely not get to it until Jan.

At that time you will have a PR to review then. I understand you don't want to waste anyone's time. But for any kind of convergence and migration path for autocomplete-plus to exist, that's what needs to happen so you have something to consider.

@joefitzgerald
Copy link
Contributor

I want to be clear that I am not sure this is the best approach.

@benogle We now have 4 people who are very actively contributing to autocomplete. It would be helpful if you consider this a possibility and work with us to guide the effort in a directionally correct way. We've already taken hints from you and others and used that as the basis for prioritization.

The better you can (conceptually / functionally) describe your ambitions for autocomplete, the more we can align the resulting autocomplete-plus > autocomplete PR to that.

@benogle
Copy link
Contributor Author
benogle commented Dec 15, 2014

We definitely appreciate the enthusiasm, but none of us have time right now to dig into this, so we cant provide legit guidance yet.

The better you can (conceptually / functionally) describe your ambitions for autocomplete

Our ambitions right now are to use / create something that can be used for a long time. But we dont have any details beyond that at this time.

My biggest worry overall is that we'll make people upgrade / write providers or related autocomplete interactions twice. Updating packages sucks, and we just want to minimize that moving forward.

@joefitzgerald
Copy link
Contributor

@benogle I think your concern about upgrading providers and the work involved in switching APIs might assume there's more providers in the wild than there are. There aren't many, and the active ones are almost entirely represented by people in this thread, asking to move this forward:

Additionally, there are users of atom-autocomplete-plus-async: https://github.com/search?q=atom-autocomplete-plus-async&type=Code&utf8=%E2%9C%93 who need to move regardless because of core API deprecations. Step 1 is to bring them into the fold of autocomplete-plus by adding async support.

We've established a gitter room here: https://gitter.im/atom-community for further discussion and collaboration, so we'll use that to rally the provider authors when breaking changes are introduced, providing temporary backwards compatibility where possible.

@thedaniel
Copy link
Contributor

We will likely not get to it until Jan.

At that time you will have a PR to review

We are looking forward to it!

@edubkendo edubkendo mentioned this issue Dec 23, 2014
Closed
@joefitzgerald
Copy link
Contributor

@benogle A quick update on the provider landscape: I've significantly updated https://github.com/atom-community/autocomplete-plus/wiki/Suggestion-Provider-List with the providers / forks of autocomplete I could find.

It was necessary to go hunting for additional providers, because the providers which directly depend on autocomplete-plus in their package.json are causing an issue with autocomplete-plus: we switched to an HTMLElement based view, and https://github.com/atom-community/autocomplete-plus/blob/469d669ff89f837e3fa15a30bc5c2e5e0302bd49/lib/select-list-element.coffee#L157 is occurring multiple times, which is not valid.

Question: do we need to call document.registerElement when we're using atom.views.addViewProvider?

@benogle benogle added the atom label Jan 20, 2015
@benogle benogle mentioned this issue Jan 20, 2015
Closed
25 tasks
@thedaniel thedaniel mentioned this issue Feb 22, 2015
Closed
@Henje Henje mentioned this issue Feb 23, 2015
Closed
@mnquintana
Copy link
Contributor

Are there any updates on the direction for autocomplete going forward? (ie. is Atom going to adopt autocomplete-plus now?)

@kevinsawicki
Copy link
Contributor

Are there any updates on the direction for autocomplete going forward?

It is definitely in progress, we shipped two new autocomplete-plus providers this week, autocomplete-html and autocomplete-css

I would guess it would start to ship with Atom in the next couple weeks or so

@joefitzgerald
Copy link
Contributor

... And we're more than happy to facilitate transition of the repo from https://github.com/atom-community to https://github.com/atom, as well as autocomplete-snippets and autocomplete-paths - if desired.

edit: or upstream it to https://github.com/atom/autocomplete.

@garex garex mentioned this issue Feb 28, 2015
Closed
@thedaniel thedaniel mentioned this issue Mar 5, 2015
Closed
@steelbrain
Copy link
Contributor

Tara Rum Pum, Bump

@benogle
Copy link
Contributor Author
benogle commented Mar 5, 2015

This is happening. I cant commit to a specific date, but autocomplete-plus will be the main deal soonish.

@russlescai
Copy link
Contributor

👍

@brendanfalkowski
Copy link

Markup closing would be a great core feature for the autocompleter: https://github.com/mrhanlon/less-than-slash

@joefitzgerald
Copy link
Contributor

Markup closing would be a great core feature for the autocompleter: https://github.com/mrhanlon/less-than-slash

That wouldn't be a core feature but it sounds like a great provider. Would be cool if the current package converted to become an autocomplete-plus provider.

@brendanfalkowski
Copy link

@joefitzgerald Ah, I'll suggest there. Maybe wrong word choice, meant: would be nice if "Atom just behaved this way by default" rather than it belongs in this package specifically. This seemed like the right place among the roadmap tasks.

@brendanfalkowski brendanfalkowski mentioned this issue Mar 11, 2015
Closed
@thedaniel thedaniel mentioned this issue Mar 15, 2015
Closed
@sandstrom
Copy link

A wish would be 'inline-autocomplete', i.e. an UI-less mode where a keypress will rotate among the alternatives (similar to how it works in Textmate). To be clear, this should be an opt-in mode, not mandatory.

This package supports this, but it's not as nicely integrated with Atom as the regular autocomplete package, and since this is a core feature of an editor I'd much prefer using an official package.
https://atom.io/packages/inline-autocomplete

@steelbrain
Copy link
Contributor

-1 for inline-autocomplete.
Because I use autocomplete to not only get autocomplete but to also get the type of the variable, for example, identify if it's a Map<string,mixed or Map<string,string.

Auto-Complete-Plus provides a label attribute that serves this purpose grealy.

@sandstrom
Copy link

@steelbrain I'm thinking of an optional, opt-in, mode. You wouldn't be forced to use it.

@benogle
Copy link
Contributor Author
benogle commented Mar 16, 2015

A wish would be 'inline-autocomplete',

I think this should be a separate package. For the people who want this behavior, they can disable the default, and install an inline-autocomplete package.

@benogle benogle mentioned this issue Mar 19, 2015
Closed
@zslabs
Copy link
zslabs commented Apr 8, 2015

Just throwing in my +1 on an AutoComplete system that can stand-up against PHP Storm's. For example, working in a Laravel app, if I start typing:

Route

it gives me options on what class to import and even tells me when I have imported classes that are not in use in the current doc, which is fantastic. This is the ONLY feature that is keeping me from moving to Atom full-time -- right now it's just for frontend work.

https://www.jetbrains.com/phpstorm/help/class-name-code-completion.html

@benogle
Copy link
Contributor Author
benogle commented Apr 8, 2015

@zslabs out of the box, it wont provide PHP intelligence. We will be bundling autocomplete-plus in the near future. You can install it today and get a much better experience over the built-in autocomplete. You may get some mileage out of @steelbrain's atom hack package. Also, I do know facebook will be soon releasing nuclide soon, which will include hack tooling, likely with autocomplete providers for PHP.

@benogle
Copy link
Contributor Author
benogle commented Apr 8, 2015

A note to everyone following this issue: there is a plan for bundling autocomplete-plus with core outlined in https://github.com/atom-community/autocomplete-plus/issues/351

I'm locking this issue. Please comment or question on the autocomplete-plus issue!

@atom atom locked and limited conversation to collaborators Apr 8, 2015
@atom atom locked and limited conversation to collaborators Apr 8, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
atom enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Bundle Autocomplete-plus instead of autocomplete atom/atom
0