You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our list of search proposals is built synchronously and the first call to the SearchEngine to retrieve types is expensive and blocks rendering of the proposal list until it returns. This makes for a crummy user experience.
A few things to consider:
can we warm up the type cache so that this first call is cheaper?
how hard would it be to make search proposal rendering more asynchronous?
if we can make it asynchronous how can we communicate to the user that the results are (as of yet) incomplete?
in general, how best can we communicate to the user when the search "index" is being "built" (which is to say, when search results will be reliable) [1](Note that in some senses this transcends searchbox searches since analysis state impacts code completion, problem markers, etc.)
[1] OS X spotlight presents a message in their pull-down that says something like this: "Search results may not include all matches until Spotlight finishes indexing the contents of your computer." In addition, they present a progress bar with an estimate ("Indexing my-computer -- About 35 minutes remaining").
The text was updated successfully, but these errors were encountered:
Our list of search proposals is built synchronously and the first call to the SearchEngine to retrieve types is expensive and blocks rendering of the proposal list until it returns. This makes for a crummy user experience.
A few things to consider:
[1] OS X spotlight presents a message in their pull-down that says something like this: "Search results may not include all matches until Spotlight finishes indexing the contents of your computer." In addition, they present a progress bar with an estimate ("Indexing my-computer -- About 35 minutes remaining").
The text was updated successfully, but these errors were encountered: