3 ms·
> Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system a
by zxzax 5y ago
> Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system at all.
So would a simple search in that folder? I don't see what is special about type-ahead here. I'm not talking about recursive search, that can already be disabled in Nautilus if you don't want it. I think this another reason is why it's bad that people get so outraged about this, a lot of the anger is directed at recursive search when really the solution there is to just fix or disable recursive search. Bringing back type-ahead is not the only way to deal with the problem. Another option would be to speed up recursive search so that it uses your suggestion first to do a fast search and quickly display results from the current folder before recursing, that would be the best of both worlds.
>By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory.
That could also be solved with an intentional search option to search by prefix, maybe with a button and bound to a certain key that makes it obvious and not confusing what's happening. I'm not saying it's bad to search by prefix.
- jstimpfle 5y agoI don't know, I haven't tested if that is fast, but I'm assuming it does hit the disk again (since they refused to add another "feature", if "Type Ahead" even deserves that name). Even it was fast, which I assume it is not really, I would prefer to have usable defaults without having to hunt for an obscure setting on every computer I happen to walk to, which is usually not even my own. And as many other commenters on that gitlab.gnome thread described, I would much prefer to not to have the list filtered. And also, I would strongly prefer not to have to disable/toggle this setting again to actually do a recursive search. I just don't understand how it can be so hard to communicate why the existing status was so much better. And why the current status is unusable. I guess only people who never actually used that earlier feature don't understand. But I will try that setting out next time... I hope then, that they fixed their stupid settings manager, which, at least some years ago, was some daemon that wrote to a binary database, and that frequently crashed, and then forgot some of its settings. > That could also be solved with an intentional search option to search by prefix, maybe bound to a certain key that makes it obvious and not confusing what's happening. The current search does just that, it's extremely confusing. It doesn't have a real search box, it is triggered as soon as you type the first key (which might be accidental), at which point it switches to a different UI state - and it's "flickering", it takes ages for the process to complete, and what your following key presses do within that timespan is very much dependent on the timing of the updates from Nautilus... I don't understand why you keep defending it. It's a huge disaster on all fronts. It would be soooo much better if they would just protect that messy imperfect search thing by a Ctrl+F combo, and otherwise do the simple Type-Ahead thing. It might be only like 20 lines of code to change it....
- deleted 5y ago[deleted]
- zxzax 5y agoAt least from my read of the gitlab issues, I don't think anyone is saying that the current solution doesn't have problems. The idea is to get those problems fixed instead of ditching the current solution entirely, or making it an optional toggle (which would make even more likely that nobody fixes the issues). For me personally, I did use type-ahead but my feeling is that a really good and fast search would make it obsolete.