I'm contributing to a Sublime Text 2 plugin for Scala, that integrates with ensime (a headless Scala IDE server).
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).