GNOME Bugzilla – Bug 691978
type ahead search is too slow
Last modified: 2014-01-13 01:28:25 UTC
If I'm in a folder, and I see a file name "bob"... and I type "bob", I expect the result to be instant.. But it's not! On Fedora 18
I want to emphasis, that this results in a breakage of a common workflow. Usecase: I want to navigate to foo/bar/baz (I use the word 'navigate' on purpose, because I think it is a different action then 'search'. Knowing where I want to go vs. dont know where to go exactly.) prior to 3.6 I type: foo->RETURN->bar->RETURN->baz->RETURN since 3.6 I have to do the following: foo->WAIT_SOME_TIME->RETURN->bar->WAIT_SOME_TIME->RETURN->baz->WAIT_SOME_TIME->RETURN WAIT_SOME_TIME is about 1 sec on my 3 years old notebook. Suggestions: 1. Make the search so fast, that WAIT_SOME_TIME is negligible. Also make sure that when typing 'foo', 'foo' is display before 'superfoo' (see #688772). 2. Cache hitting 'RETURN' and open the first file/folder after the search is complete (This is how gnome-shell works on my slow notebook. Typing firef->RETURN opens firefox, even if the search takes longer than my typing). #688772 must also be solved in order to make this work. 3. Came up with an other idea. Maybe create two distinguish methods for navigating and searching.
This is still a problem. After upgrading, I've found myself shying away from type ahead search: it's just much faster to use a mouse. This is a very unfortunate regression in functionality which has negatively impacted a very common workflow of mine. Moreover, the search functionality doesn't replicate the old behavior in at least one important case. Say I have the directory structure, hi/ hi/yyy/ hi/yyy/asdf/ hi/yyy/asdf/hello world hi/asdf With the previous type-ahead find functionality, if I wanted to open asdf I could simply begin typing asdf. With search, I type asdf and instead find that hi/yyy/adsf is selected as it is a directory where hi/asdf is a file and therefore comes later in the sort order. The simple fix for this would be to first filter the current directory based on the search criterion and ensure any results come first in the sort order. Only after these results would hits from child directories appear, thus guaranteeing that the old functionality is reproduced (and hopefully avoiding the latency of a search)
(In reply to comment #2) > Moreover, the search functionality doesn't replicate the old behavior in at > least one important case. Say I have the directory structure, > > hi/ > hi/yyy/ > hi/yyy/asdf/ > hi/yyy/asdf/hello world > > hi/asdf > > With the previous type-ahead find functionality, if I wanted to open asdf I > could simply begin typing asdf. With search, I type asdf and instead find that > hi/yyy/adsf is selected as it is a directory where hi/asdf is a file and > therefore comes later in the sort order. Oh, I think that's wrong too. I can see the same thing if I enable "Sort folders before files" in the Preferences. I've reported it as bug 699629. Thanks for the example. When "Sort folders before files" is disabled, the result from current the directory will always be ranked higher than a "deeper" result, just like you expect it to be.
*** This bug has been marked as a duplicate of bug 681871 ***