type ahead search behavior

[Ash]

It would be good if type ahead searched in current folder instead of just filtering words starting with typed phrase. for example typing .deb would show .deb packages in the directory.

[Jeremy Wootten (jeremywootten)]

I presume by "type ahead" you mean searching by directly typing at the view (without selecting the pathbar) rather than the completion facility when typing a path.

If you press <Ctrl>F before or after typing your search term then the first section of the search results window gives you the results you require. I think most other file managers use a "begins with" search in the current directory in response to direct typing so, presumably, this is now the expected behaviour and if you are using the function for rapid navigation is what you want.

For the example you give, you could also sort on the type (at least in list view) to group all the .deb files together.

[Ash (ash1991)]

Yes most the file managers(including nautilus and nemo) use a "begins with" search as type-ahead and I did know the other file managers behavior. Let's make it more clear:
When someone uses the search(or type-ahead feature) they use it for one of the following reasons:

1. They want to search for a phrase in all folders and subfolders(this is what search is for)
2. They need just filtering the current folder items(files/folders) with their beginning phrase.(this is what the current type-ahead feature is for)

3. BUT sometimes you know a file name contains a phrase but it is not at the beginning.

Regarding implementing this feature("search in current folder" instead of "begins with search in current folder") I think there are some points:
1. It's obvious that using search would give the user the results but it's the same for type-ahead.
2. The upside of implementing this feature is obvious and besides you can't navigate between results in search function like you can in type-ahead search.(they might be in folders other than the current one)
3. The downside might be you get more results and it might make results pane overcrowded but I think it's not that noticeable especially when we consider that: First, other filemanagers don't show the results list in their type-ahead feature(you are just able to navigate between them) and Second, even full-search in pantheon-files shows 10 results and it's assumed that when one does even a full-search the criteria is well chosen that there will be at most 10 results so with the same assumption the "search in current folder" results pane won't be overcrowded. (BTW, IMO even not limiting the results to 10 won't overcrowd the search pane because we are just looking in a folder and not in subdirs)

After all, I think the advantages outweighs the disadvantages and it's worth deviating a bit from what other filemanagers do especially considering pantheon-files features and design assumptions.

[Jeremy Wootten (jeremywootten)]

I'll refer this to the elementary UX for their opinion.

[Danielle Foré (danrabbit)]

I think in an ideal world the same thing happens when you start typing as when you press ctrl + F. I can't remember the reason for why it wasn't implemented in this way, but I think it just comes down to us ranking results appropriately and using categories in the returned results.

The hit at the top of the list should probably be the closest to the exact match in the current directory. So that you can, for example, quickly navigate by typing. So if ".deb" was the search term we should list matches for "starts with .deb" first in my opinion.

In the case of the example of finding .deb, unless there's a folder called .deb I don't think there would be any real conflict in adding "includes .deb" as the next set of results.

Then of course we search outside of the current directory after that.