Comment 6 for bug 1666676

So all of this tells me that tracker isn't a replacement for typeahead search. They have two entirely different use cases:

 * Typeahead search only affects the currently displayed directory (or should anyway -- you search through what you see, not through the entirety of the file system). It is fast as it's only one readdir(), and nautilus already did that as it's displaying at least the first portion of the directory and there is no need to stat() the individual files. It also needs to be instant and correct even when I just copied a large directory from somewhere else or am looking at a remote sftp/cifs directory, and work everywhere.

 * Tracker imposes a huge cost due to always indexing everything (even if you never search for it). It's good for tasks like "where did I put my files last week". However, it is necessarily only approximate, as it has some delay (which can be quite large if you are on battery, or just copied a large bunch of files), and not universal (non-XDG directories, remote file systems), etc.

So I don't see how "enable tracker" can ever be a replacement for typeahead search, and TBH I still don't buy that we have to penalize each and every installation with the tracker overhead even though most people don't do full-hard disk searches all the time (and many don't do this at all). And if you do need a "search through my home dir", you *still* need to do an actual search due to the latency/approximative nature of indexing. It's not an acceptable answer to say "sorry, we don't show the file you just downloaded as we didn't get to indexing it yet".

I see tracker as a nice opt-in (!) feature for people who often do full searches, so this might become a checkbox in the search box?