Sublime Forum

Completion API Questions (is this possible?)

#1

Hiya,

I’m contributing to a Sublime Text 2 plugin for Scala, that integrates with ensime (a headless Scala IDE server).
github.com/sublimescala/sublime-ensime
github.com/aemoncannon/ensime
ensime 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’t
ask 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 all
    possibilities, 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).

Thoughts?

Thanks,
Aemon Cannon

0 Likes

#2

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.

0 Likes

#3

Thanks for the reply.

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, and
suddenly 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 matching
I 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.

0 Likes