Public bug reported: I was going to report this upstream, but then I remembered that type- ahead selection of files was removed by retarted upstream Nautilus maintainers, and it has been patched back by Ubuntu as per https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016
So: Steps to reproduce: 1) Have a folder with these files: aaa.txt aaa.txt~ (hidden) aab.txt~ (hidden) aac.txt 2) Open the folder in Nautilus; make sure that the "show hidden files" option is NOT enabled => so you only see aaa.txt and aac.txt 3) Type: "aa" 4) Hit the down arrow key several times. Expected behavior: * Since hidden files are not being shown, they should not be selectable by type-ahead. Hence, - after typing "aa", aaa.txt should be selected - at the first keystroke on the down arrow, aac.txt should be selected Observed behavior: - After typing "aa", aaa.txt is selected, as expected - At the first keystroke on the down arrow, no file seems to be selected. aaa.txt is no longer highlighted but aac.txt isn't either. Under the hood, I guess the aaa.txt~ file is "somehow selected" (but if you hit Enter nothing happens, thank god) - At the second keystroke, still nothing seems to change: still no file apparently selected. But under the hood, aab.txt~ is probably "somehow selected" - At the third keystroke, finally aac.txt is selected, proving that Nautilus is somehow selecting files even if they are hidden. Behaving like a file is selected (in that the previous selected one is unselected and that you can skip to the next one) while it is not even visible is INCONSISTENT. The most reasonable expected behavior is to select and loop through only visible files, so, if hidden files aren't being shown, only non-hidden files must be considered, while if hidden files are being shown, then they must be considered. Another sensible behavior could be to make the hidden files that match the typed string become visible, and highlight them when they are selected, but that would eventually lead to counterintuitive behavior and design issues (what do you do when the type-ahead box disappear? turn back the hidden files to invisible?) == ANOTHER EXAMPLE == Say you have, in a folder: aaa.txt~ (hidden) aab.txt You type "aa" Expected: aab.txt should be highlighted and selected Observed: nothing is highlighted, which is exactly the same that would happen if no file matching the typed string existed. So you may even think the file doesn't exist (if you don't look carefully enough, which usually you don't want to, because that is why you use type-ahead in the first place), or you see it right in front of your eyes and you say "why the heck isn't it found??". Only if you think about using the arrow keys you will realize that the file you're looking for actually exists. Which means that TYPE-AHEAD IS BASICALLY UNRELIABLE: you type something, you see nothing selected, and that's no guarantee that no matching file exists, until you use up/down arrow keys. (actually, you will never be sure: what if there were hundreds of hidden files starting with the typed string? Unlikely but possible) The whole design of the type-ahead find thingie (which is a very useful, vital feature) is actually shitty. It lacks at least one of two things: either 1) showing the number of matches found or 2) changing the color of the typed text or its background when no match is found ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: nautilus 1:3.10.1-0ubuntu9.7 ProcVersionSignature: Ubuntu 3.13.0-55.94-generic 3.13.11-ckt20 Uname: Linux 3.13.0-55-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jul 22 23:29:18 2015 GsettingsChanges: b'org.gnome.nautilus.list-view' b'use-tree-view' b'true' b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions', 'mime_type', 'where']" InstallationDate: Installed on 2013-10-11 (649 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) SourcePackage: nautilus UpgradeStatus: Upgraded to trusty on 2014-05-24 (424 days ago) ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug trusty ** Description changed: I was going to report this upstream, but then I remembered that type- ahead selection of files was removed by retarted upstream Nautilus maintainers, and it has been patched back by Ubuntu as per https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016 So: Steps to reproduce: 1) Have a folder with these files: - aaa.txt - aaa.txt~ (hidden) - aab.txt~ (hidden) - aac.txt + aaa.txt + aaa.txt~ (hidden) + aab.txt~ (hidden) + aac.txt 2) Open the folder in Nautilus; make sure that the "show hidden files" option is NOT enabled - => so you only see aaa.txt and aac.txt + => so you only see aaa.txt and aac.txt 3) Type: "aa" 4) Hit the down arrow key several times. Expected behavior: - * Since hidden files are not being shown, they should not be selectable by type-ahead. Hence, + * Since hidden files are not being shown, they should not be selectable by type-ahead. Hence, - after typing "aa", aaa.txt should be selected - at the first keystroke on the down arrow, aac.txt should be selected - Observed behavior: - After typing "aa", aaa.txt is selected, as expected - At the first keystroke on the down arrow, no file seems to be selected. aaa.txt is no longer highlighted but aac.txt isn't either. Under the hood, I guess the aaa.txt~ file is "somehow selected" (but if you hit Enter nothing happens, thank god) - At the second keystroke, still nothing seems to change: still no file apparently selected. But under the hood, aab.txt~ is probably "somehow selected" - At the third keystroke, finally aac.txt is selected, proving that Nautilus is somehow selecting files even if they are hidden. - - Behaving like a file is selected (in that the previous selected one is unselected and that you can skip to the next one) while it is not even visible is INCONSISTENT. + Behaving like a file is selected (in that the previous selected one is + unselected and that you can skip to the next one) while it is not even + visible is INCONSISTENT. The most reasonable expected behavior is to select and loop through only visible files, so, if hidden files aren't being shown, only non-hidden files must be considered, while if hidden files are being shown, then they must be considered. Another sensible behavior could be to make the hidden files that match the typed string become visible, and highlight them when they are selected, but that would eventually lead to counterintuitive behavior and design issues (what do you do when the type-ahead box disappear? turn back the hidden files to invisible?) - == ANOTHER EXAMPLE == Say you have, in a folder: - aaa.txt~ (hidden) - aab.txt + aaa.txt~ (hidden) + aab.txt You type "aa" Expected: aab.txt should be highlighted and selected Observed: nothing is highlighted, which is exactly the same that would happen if no file matching the typed string existed. So you may even think the file doesn't exist (if you don't look carefully enough, which usually you don't want to, because that is why you use type-ahead in the first place), or you see it right in front of your eyes and you say "why the heck isn't it found??". Only if you think about using the arrow keys you will realize that the file you're looking for actually exists. - - Which means that TYPE-AHEAD IS BASICALLY UNRELIABLE: you type something, you see nothing selected, and that's no guarantee that no matching file exists, until you use up/down arrow keys. - + Which means that TYPE-AHEAD IS BASICALLY UNRELIABLE: you type something, + you see nothing selected, and that's no guarantee that no matching file + exists, until you use up/down arrow keys. (actually, you will never be + sure: what if there were hundreds of hidden files starting with the + typed string? Unlikely but possible) The whole design of the type-ahead find thingie (which is a very useful, vital feature) is actually shitty. It lacks at least one of two things: either 1) showing the number of matches found or 2) changing the color of the typed text or its background when no match is found ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: nautilus 1:3.10.1-0ubuntu9.7 ProcVersionSignature: Ubuntu 3.13.0-55.94-generic 3.13.11-ckt20 Uname: Linux 3.13.0-55-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jul 22 23:29:18 2015 GsettingsChanges: - b'org.gnome.nautilus.list-view' b'use-tree-view' b'true' - b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions', 'mime_type', 'where']" + b'org.gnome.nautilus.list-view' b'use-tree-view' b'true' + b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions', 'mime_type', 'where']" InstallationDate: Installed on 2013-10-11 (649 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) SourcePackage: nautilus UpgradeStatus: Upgraded to trusty on 2014-05-24 (424 days ago) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1477322 Title: Select-by-typing select hidden files even if they are not shown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1477322/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs