Type past suggestions box & remove extra input box. about autocomplete HOT 15 CLOSED

The main reason we use a separate input box is that we want to be able to "fuzzy find" on the suggested completions. So if you wanted to jump to "borrows" you could type "bws" or something similar. It seemed strange to us to insert the gibberish associated with fuzzy completion directly in the buffer.

I can see this mode being an option, one I would probably associate with the auto-popup of the completer that a lot of people seem to want. If you're manually triggering it, being able to fuzzy find in a large list is really convenient.

Thoughts?

from autocomplete.

Take a look at
http://discuss.atom.io/t/autocomplete-autocomplete-without-hotkey/2739

The autocomplete is what I think everyone expects an autocomplete to be. typing directly into the dom, getting suggestions constantly or on a delay instead of using a hotkey etc..

The one big change I suggested here:
http://discuss.atom.io/t/autocomplete-autocomplete-without-hotkey/2739/16

Would be to open up this package for other packages to subscribe to. I explain myself pretty well in that post but to summarize, any package could be a subscriber to the autocomplete box. The subscriber would listen to a buildList event that would send the prefix. the subscriber would respond with an array of suggestions and the autocomplete would compile all of these together and display them. You could also subscribe to a onSelect event too that would get fired if the subscrubers suggestion was selected. It could trump default behavior or add and bubble up etc...

@saschagehlich has done a fantastic job on this package but really this should be default behavior IMO.

Thoughts?

from autocomplete.

Making it auto-deploy

I love the autocomplete as it currently exists, but I hear you and everyone else that they want an option to auto-deploy. It should probably be the default based on the current popularity. I'd like it to be a config option. If auto-deploy is enabled, we don't show the mini-editor. If it's disabled we leave the behavior as it is.

We just need to be able to search the word list quickly enough to avoid degrading the typing experience. I'm not sure the current implementation is fast enough yet so we'll have to investigate, but we have the technology to optimize it if it isn't.

Making it pluggable

I like the idea of building out a pluggable API for word list providers. Off the top of my head, it seems like we'd want to register these providers globally on the autocomplete package. When the autocomplete is triggered (or when we attempt to auto-deploy it after a change), we call each provider in reverse order of registration with the current word prefix and suffix as well as the syntactic scope of the cursor.

A provider can return an array of words or undefined. If a provider returns a list, we check if the provider .isExclusive(). If it's not exclusive, we continue calling providers. Otherwise we stop and just display the words aggregated so far.

from autocomplete.

@nathansobo

I did some performance tweaks for my autocomplete+ package and it works very smoothly on my machine, even with something like three.js with > 38k LOC it is responding very quickly. I'll add hotkey-based activation back in for older machines though.

I really like your idea of globally registering item providers and I'd like to implement that in autocomplete+ ASAP (= tonight). Could you give me a little hint on how to implement that? I'm not really familiar with atom's eventing stuff - is there a global event "mediator" that I can make use of?

from autocomplete.

@nathansobo

What happens if multiple subscribers are exclusive?

If you were in my code base I would argue that a function should never return undefined because if you call a function with the expectation of a value, undefined is the opposite of that, it literally means unassigned value, however null is appropriate because null is an assignment value that represents no value. But thats neither here nor there because this is not my code base ;)

I think you should make a pull request to @saschagehlich code or sync up with him because he is the furthest along but it sounds like you have more internal knowledge that would round out these features.

from autocomplete.

@saschagehlich:

I'm going to add a better API to atom.packages today to help you to get hold of another package's top level module in a coherent way. So long as the code is well tested and we preserve the existing manual trigger behavior as an option, I'd definitely be open to incorporating this kind of behavior into the default autocomplete package if you're interested.

@JAStanton:

You're always welcome to make suggestions. I've been conflicted on the null vs undefined issue for a long time now, as especially in CoffeeScript they are quite similar. The reason I like going with undefined is that it often makes code that's guarded by if statements more terse. You can omit the else null branch and it just returns undefined. That's a pragmatic rather than philosophical motivation. We'd probably just want to skip any "falsy" value such as null, undefined, or false.

from autocomplete.

@nathansobo: I'm going to fix the specs and refactor the code so that we have a good base we can work on. :)

from autocomplete.

Also, just a heads up. It would probably be easier to do these changes as two separate PRs. One for the auto-deploy, and another for the pluggable word list providers.

from autocomplete.

Agreed

from autocomplete.

@nathansobo
In regards to atom.packages, I agree that this should be done because right now I don't think it's possible for me to extend the Autocomplete package by doing something like:

Autocomplete = require './path/to/autocomplete'
class newAutoComplete extends Autocomplete

Also what would my packages.json dependencies look like? I want to ensure that it exists and that someone didn't remove that package.

This is comment is forking from the original discussion so maybe we should carry this somewhere else.

The way I solved this way to copy and paste the entire Autocomplete class into my code. :(

from autocomplete.

@saschagehlich Sorry to hijack the thread again. After some deliberation there's not clarity that we're ready to change the core APIs around this. I have a suggestion for now, but beware that this API will probably change.

The atom.packages.activatePackage method takes a package name and returns a promise. When the promise is resolved, you are handed a package object with a mainModule property. That's the main module of the activated package (with the activate method, etc).

You could potentially define other methods there that comprise the package's top-level API.

Edit: removed speculation

from autocomplete.

@kevinsawicki suggests a way this could be inverted, similar to how we handle snippet loading in the snippets package. The advantage here is that a package that exposes word list functions doesn't depend on a particular API of the autocomplete package. Another advantage is that any autocomplete competitor can also use word list functions exposed by other packages.

The autocomplete could define an API that adds the following package.json fields to packages that want to access the api:

{
  "name": "my-package",
  "autocomplete": {
    "dynamicWordBuilder": "./lib/my-packages-word-builder"
  }
}

In the autocomplete package:

for pack in atom.packages.getAvailablePackages()
  if pack.metadata.autocomplete.dynamicWordBuilder
     @wordBuilders.push(require(pack.metadata.autocomplete.dynamicWordBuilder))

from autocomplete.

@nathansobo The second approach would only allow one word builder per package, right? I can't think of a case where you need multiple word providers, but it's a little more dynamic. Also, I don't like "polluting" the package.json :/

from autocomplete.

Let's continue this conversation in #10.

from autocomplete.

I closed this since it is being continued in #10

from autocomplete.