I'm contributing to a Sublime Text 2 plugin for Scala, that integrates with ensime (a headless Scala IDE server).https://github.com/sublimescala/sublime-ensimehttps://github.com/aemoncannon/ensimeensime accepts a socket connection and then services RPC calls for IDE-like functions. e.g. type at cursor, completions at cursor, goto definition, etc, etc.There's already a full-featured emacs client, but I'm eager for the sublime client to be even better ; )

With respect to completions, the problem I'm having is that sublime seems to want _all_ the completions at once. To elaborate, say I am looking for the method'typeAt', and I type 'ty' before the 'on_completion_query' listener run, in that handler I ask ensime (via the socket connection) for completions at that location. Assume I can'task for _all_ the completions, as there hundreds and hundreds and I need to return synchronously (must block in the on_completion_query). So I ask for the first 20, which returns lickety-split.If 'typeAt' is in those 20, then great. Otherwise, as you continue to type, one of two things happens:

1) Eventually you exhaust the set of 20, and sublime does another query. This usually gets you to the desired result, but in a non-intuitive way.. as it appears that you've exhausted allpossibilities, and then suddenly there's more!

2) If 'typeInAFlowerPot' is in the first 20, then sublime's fuzzy matching will match the non-contiguous 'A' and 't' and consider that good enough. No more completions are requested and you're stuck.

If you could somehow return MORE_COMPLETIONS_AVAILABLE from on_completion_query, which would cause sublime to re-query more eagerly (perhaps before appealing to fuzzy matching?), that would be cool..

I've considered having an explicit completion trigger which queries for _all_ results, but I want it to feel naturally integrated with the editor (pervasive completions as you type, with no perceptible delay).

Returning hundreds, or even thousands, of completions shouldn't be an issue (i.e., shouldn't cause any perceptible delay). If the number of completions is as issue, the plugin can do a first pass filter using the provided prefix ("ty" in this case), and only return potentially matching ones.

I'm not sure that the proposed solution would interact nicely with the fuzzy matching, as the best match may be the last one returned by a plugin, and thus we'd want to query for all available completions in any case to ensure that it gets picked up.

> Returning hundreds, or even thousands, of completions shouldn't be an issue (i.e., shouldn't cause any perceptible delay)I trust that is the case with sublime itself, but it is not so with the Scala compiler. Add the additional delay of transferring things from the server, andsuddenly things are very sluggish.

> ..do a first pass filter using the provided prefix.This was the first thing we tried. Prefixes like 'get' are just too numerous.

> I'm not sure that the proposed solution would interact nicely with the fuzzy matchingI see your point. It may be that streaming completions incrementally doesn't fit comfortably into the sublime model. I was hoping there would be some trick..Perhaps a custom show-all-api-completions-now key is the way to go.