Design the Searcher (Autocomplete)

[iamrecursion]

Summary

One of the key pillars of Enso Studio's usability is the intelligent nature of its searcher. The searcher can be thought of as autocomplete on steroids. It takes into account obvious things like the location in code and the contextual type, but also more user-focused things such as unimported symbols, searching within documentation, and so on.

Value

We will be able to provide well-ranked candidate completions to Enso Studio for use in the searcher.

Specification

The design for the searcher should be coherent with the needs to operate within the LSP Completion functionality. We can also consider applying elements of the work-in-progress LSIF specification to help provide rapid completions while the language server spools up.

• Design the user experience for the node searcher.
• Determine the criteria for gathering completions. This is primarily a question of where.
• Determine the criteria for ranking completions. Examples follow.
  • Hints should be scored on a type match. For example, if we have a type 5, foo : 5 -> String scores higher than bar : Nat -> Dynamic, scores higher than baz : Any -> Any. This should be done by heuristics initially, and later by querying the typechecker for subsumption relationships (the notion of specificity discussed in the types design document).
  • Information contained in the tags section of the documentation should also be used to rank candidates.
  • Please note that this ranking algorithm will be required to get more complex in the future, so please design it for extensibility and high performance.
  • Local variables should rank higher than global symbols.
• Record these design decisions in the relevant design document.

Acceptance Criteria & Test Cases

• The searcher design has been established and written down concretely.