Restore interactive_search.patch (type-ahead search)

Hey all,

As Jeremy mentioned, I think it's the best idea to drop this patch and use the default search utility of Nautilus.

For users
---------
One of my main interests in the last 4 releases was to improve this situation, whether search doesn't replace the use cases of type ahead.
We iterated on it and made several improvements:
- Searches on the current folder are done with priority
- Performance have been improved in several ways
- Result of the current folder are clearly differentiated by not displaying the "Original Location"
- We switch by default to list view when searching, so the locations or the file are clearly shown
- We added a preference for permanently search recursively or only in the current folder.
- The view used while searching can be changed independently of the default view when not searching.
- Using tracker, search in most common folders is immediate.

I believe all except one use case is covered in the current search, taking into account lag and performance too. The use case that is not covered is when the user wants to navigate to a folder that it's close to a name. For instance user wants "Pictures" folder and user searches for "Osomething", so most probably the next folder by alphabetical order is "Pictures". However I believe this is easily replaced by just searching for "Pictures" or "Osomething" and then right click -> open item location which opens the folder (it can be the current one) and selects the file, effectively replacing type ahead (again if tracker is enabled so lag is not an issue).

We are still interested in evolving this more, and we are open to feedback and making the effort on improving the situation as long as it can fit, and doesn't clash, with our vision for search.

For developers of Ubuntu
------------------------
The code on nautilus-window-slot and nautilus views is extremely delicate. You really need to understand all the interactions that happens under it to be able to modify the code expecting any reliability. Needless to say the patch that is currently used is missing this reliability, receiving crashes both in Ubuntu and upstream where we don't even know why this happen.
Also this code has been refactored several times in the past, because it needed to, and it will be more refactored in the future. You will need to update the patch every release without exception, which I don't think is the best investment for Ubuntu if they are going to replace everything with Unity 8.
So current situation is a lose-lose, trying to be as impartial as possible, I think using directly what upstream is using is the best solution for both parties, and even more in this part of the code.

One thing to clarify, as Jeremy mentioned, this doesn't make sense without tracker, and if the decision is to not adopt tracker, I would recommend to keep the downstream patch.

Status changed to 'Confirmed' because the bug affects multiple users.

Thanks Carlos for the detailled comment, one question though, why doesn't it make sense without tracker? If we disable recursive lookups by default the search without tracker limited to the current directly should work without performance bottleneck or issues no?

Otherwise one thing that was annoying me when I previously tried the new version is the view content changing as you type, but I guess that's by design/still the case/not going to change (it might be even more change now since your comment suggest you switch to list view automatically)...

Going back to the topic there I think we should get 3.24 without the typeahead patch and without tracker in a ppa (the GNOME team one might be good enough or we might want to get one with only those) and do a call for testing/feedback on the desktop list. Enabling tracker is going to be a bigger discussion (which is started in bug #1666676)

Jeremy,

Yes you are right, that's why we have the "model search" where we search in the current Nautilus cache. Sorry for that mistake, I had a brainfart :/

Tracker is not needed for the search to be a (fast enough) replacement of type ahead. I will clarify this in the other bug report.

"Going back to the topic there I think we should get 3.24 without the typeahead patch and without tracker in a ppa"
Sounds fine.
I'm afraid though that recursive search is going to be too slow, and people could think this is the intended behavior when is not. But this is topic for the other bug report indeed.

Hey Carlos @csoriano,

sorry for replying to such an old bug but I didn't know where else to do this. You mentioned use-case covered by search, so here are my usecases not covered by search (as far as I know).

In research projects you often have big datasets. So e.g., when I get data from an MRT-scan with a couple of thousand images, tracker is out of the question. I need to access the data immediately and can't wait for indexing.

When I want to navigate to images starting with "PBX" I just enter that for type-ahead and Nautilus jumps directly to the first file starting with that while still showing me the files before and after (according to the current sort-order). Search doesn't navigate, it searches for "PBX" and shows me all files containing PBX anywhere (after a long wait because the files aren't indexed, yet).

Sometimes I need to see files in the context of their creation time. With type-ahead I just sort by date and navigate to a specific file to see which files where created before and after the file in question.

Researcher who are already using newer versions of Gnome without type-ahead often just use PgUp/PgDown until the see what they need instead of directly navigating there.

You see the pattern: search can't replace navigation. They are two seperate things.

Thanks for taking the time to reply here. If you're interested in discussing this further, just let me know where.

I definitely can't live without type-ahead. I just upgrade from 17.04 Ubuntu Gnome to default 17.10 to test it and Nautilus is unusable without that feature.

I'm not sure why it can't be keep as default or optional behavior, but it is a huge regression to me, and to many other users I suppose.

I've been using type-ahead search for years and there's no way I can adapt to a search window opening each time I want to navigate folders. I do agree with @mniess, Search and navigation really are too different things.

Is there a way to downgrade nautilus to a usable version ?

For me it's very annoying. I migrated from Ubuntu 17.04 to 17.10 several days before, and just cant use nautilus. I'm using this type-ahead feature for navigate. At the beginning i tried to switch off recursive search in nautilus to speedup it. But when i want to use recursive search i should go to the setting and switching it on again. I even tried to replace nautilus with another file manager, but gnome can't showing desktop items without nautilus. Why type-ahead can't exists as optional setting? Type-ahead still works in open/save dialogs, why it can't be in nautilus?

That's an essential feature that should never be abandoned. I'm facing similar issues like Dmitriy did. Are there ways to patch or downgrade Nautilus? It's working perfectly in 17.04

This is an essential feature that needs to be brought back. I have the same problems as Dmitriy and drunckoder. Everything worked nicely in 17.04 after disabling recursive search.

Sorry, I spent time trying to get the old patch to work but my patch didn't work. See paragraph 2 of the bug description.

If someone contributes a working patch, the Ubuntu Desktop team may reconsider.

Found this patch: https://github.com/manjaro/packages-community/tree/master/nautilus-typeahead

Not sure if it works

As someone who constantly uses type-ahead find when browsing files (in any OS), I can't stand not having type-ahead search in a file browser. I'm replacing Nautilus for now, please fix this.

It's not as if the old behaviour needs to be completely restored. It just should be an option to use whichever behavior one likes best.

The old behaviour was one of the power features of Nautilus for a person that uses keyboard navigation. The new behaviour is dramatically different and frankly doesn't work as well for many use cases.

Lets say I want to quickly navigate to ~/code/myproject/module/__init__.py.

1. I switch to Nautilus which shows my home folder
   A. With the old behaviour: c ENTER m ENTER m ENTER __i ENTER
   B. With the new behaviour: __init__.py, and it shows me tons of __init__.py located in my home folder and all subdirectories
2. Trying to use the new behaviour and still achieve my goal I try this:
   i) module/__init__.py, no hit
   ii) module __init__.py, no hit

So, currently I see no way of navigating to the intended file without alot of hassle or reaching for the mouse. A big regression for me.

It's a shame there is no way to vote for things here, and instead weight seems given to bugs with a large number of comments / activity.

The current version of nautilus, which is the very core of Ubuntu, is broken. Search is not the same as navigation. I do not want to search my files when I know exactly where the file I want is - I want to go to it.

There are full time Ubuntu developers. This should not be waiting for a user to contribute a patch.

This is so stupid.

> One of my main interests in the last 4 releases was to improve this
> situation, whether search doesn't replace the use cases of type ahead.

Indeed, search, does NOT replace type-ahead, it's just a completely different thing, and it won't ever be a replacement, no matter how much you improve it, and regardless of performance.

The solution was pretty obvious: just DON'T replace type-ahead with search.

But no, idiocy had to prevail, as it usually does in Nautilus. That's a shame.

I wonder why Ubuntu doesn't switch to some other file manager that, unlike Nautilus, is not maintained by complete idiots.

I guess I'll have to switch to a distro that, unlike Ubuntu, is not maintained by idiots either.

OMFG, being an Ubuntu (patched Nautilus that is) user for more than 9 years I thought this was a bug with 17.10 and patiently waited for a fix ... can't agree more with "complete idiots"

This is not a huge, complex and hard to maintain feature that you just decide it is too difficult to support. Is this a mirror of the next "de-generation" of products?

OMFG

Hi all,

I am also affected by this bug (this cannot be a feature, right?).
I was wondering what went wrong during my 17.04 to 17.10 upgrade.
Why on earth was type-ahead removed?
It makes nautilus useless for any user that make use of the keyboard.
Please, reactivate this feature.
In the meanwhile, can anyone point to a decent filebrowser to replace nautilus on 17.10 and 18.04?

Hi all,

I also just migrated 1 or 2 months ago to 17.10 (because of EOL) and it's horrible.
I'm using Ubuntu mainly for work, so this change impacts my workflow quite heavily. Of course privately too.
If you don't change the default behaviour, then you will face freezes.
Most of my folders contain 100 and more subfolders and in some of them there are thousands of files.
Many projects like those of Android Studio etc. contain ten-thousands of files.
Just press a key by accident and nautilus freezes for 10 minutes and longer.

To prevent that one has to switch of recursive search and full text search.

By the heavens! This can't be the default behaviour!!!

With the old behaviour, you can jump to where ever you need to. If all folders have a unique first letter, then navigation is done with one key press.
Now, you still need to navigate through the results. Come on guys, "efficiency" is something different!
This works even in Windows, why not in Nautilus?

Btw.: I just tested the live CD of 18.04. The issue is not fixed.

Just having the option to choose the behaviour would be fine. No need to abandon one for the other.

Try this: https://launchpad.net/~lubomir-brindza/+archive/ubuntu/nautilus-typeahead

The changes are based on the patch from Arch community, with slight modifications to work on 3.26.3 release.

For each time I make a search, I use type ahead 99 times to navigate directories. In my opinion type ahead search is indispensable for using Nautilus productively.

Lubomir, what changes were required on top of the arch patch to work with 3.26.3? I'm using the Arch patch as-is on Ubuntu 18.04 and there don't appear to be any problems that I've noticed so far. But assuming your changes are necessary, could you publish them somewhere? It would be great to maybe have a public git repo that people could contribute to to maintain patches for the latest few versions of Nautilus that are in common use.

Ubuntu devs - now that there is a working patch again (and seemingly the will to maintain it by the arch community and others), might Ubuntu be able to ship a patched nautilus once more restoring this behaviour?

PPA patch is based on commit 20cd678 from https://aur.archlinux.org/nautilus-typeahead.git repo which is meant for 3.26.2 release; although it did apply on 3.26.3, it wasn't cleanly and the result didn't compile. Next marked commit is meant for 3.28.0.1, so I didn't play with it.

The changes I remember making were to nautilus-list-view.c:nautilus_list_view_set_selection() (new path2 variable), and to nautilus-window-slot.c (unclean patch apply caused another instance of configure_event_cb() to appear instead of modifying the existing one - you can download the PPA source and see that I've left the 'wrong' instance commented out in debian/patches/restore-typeahead.patch instead of removing it by mistake). Nothing major, all in all.

Guess I'll fork the AUR repo to Github?

Lubomir, thank you for doing this! Chris Billington's suggestion about being able to restore this behavior to the official Nautilus is a great one. I'd love to see official support for this feature... actually, I think it is crucial to have this option available for the users.

Agreeing. Always using type-ahead in any OS, any application really.

Having it become 10x as slow (even when never allow recursive search) is a show stopper.

It's literally the difference between having the UI responsive, and the content /already there/ being navigatable and waiting 5 seconds for a (flawed) subset of the data you were previously shown to reappear in a different place, with no possibility to continue navigation (like, you know, `FF` to navigate to the first `foo*` file and select 3 files down from there.

It's not even consistent within Nautilus itself - type-ahead works fine in a "pop up file browser" when saving a file from an application or downloading a file from a browser. It's only the fewer cases where you manually launch the file browser from the desktop that it behaves different for some reason.

It's always disappointing to see software developers of popular software get a bee in their bonnet over something like this, staunchly ignoring a widely used, simple feature simply because they themselves don't use it. I've seen this in the Atom Text editor too, where they closed the thread of 100's of posts asking for block select, with a dismissive "I don't think this thread is helping anyone anymore." So I switched to Sublime, which does have it.

Type-ahead is in literally every other OS I've tried. Admittedly not many, but when that list involves nearly every release of Windows, Linux Mint, and Fedora, you really have to wonder why someone would choose to stick their fingers in their ears over this one - not even as an option, even somewhere buried away in a config - it's just plain disabled forever - but the functionality DOES exist in the system because it works in "popup file browsers". It's like giving the middle finger to people who regularly use this productivity time-saver.

Lack of type-ahead is unbearable.

> If someone contributes a working patch, the Ubuntu Desktop team may reconsider.

Jeremy @jbicha and Carlos @csoriano ,

It sounds like someone has contributed a working and maintained patch that has not yet been merged.

Someone even created a new PPA just for this patch, but obviously this should be pushed to Ubuntu upstream.

What else needs to be done to get this merged?

(This bug is currently marked "Won't Fix". Does someone need to open a new bug to get this merged?)

Related bug in official nautilus repo

https://gitlab.gnome.org/GNOME/nautilus/issues/244

https://gitlab.gnome.org/GNOME/nautilus/issues/1157

Why the fuck was this closed???

See also the discussion on 1164016 after this idiocy resurfaced.