Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search ignores hidden files and folders #604

Closed
HifeFish opened this issue May 6, 2014 · 16 comments
Closed

Search ignores hidden files and folders #604

HifeFish opened this issue May 6, 2014 · 16 comments

Comments

@HifeFish
Copy link

HifeFish commented May 6, 2014

There is no way to include hidden files and subfolders into a search (even if they are generally set to be visible).

System: Ubuntu 14.04, Nemo 2.2.1

@petermoo
Copy link

petermoo commented Feb 3, 2016

Nemo search turned out to be useless to me. When searching for settings files and other files, I do not know if one of the directories happens to have a . in the file name. The command line "find" finds the relevant files, Nemo does not.

Nemo search is effectively wrong. Switching on the "show hidden files" is not applied to search. The results are misleading, missing critical files.

A Nemo search should search the same files as shown in the browse window.

@xenopeek
Copy link

Still happening on Nemo 3.0.6. Toggling to show hidden files and then searching doesn't find any matching hidden files or matching files in hidden directories. Counter-intuitive as the pane is showing hidden files and directories before you start searching.

@NeverUsedID
Copy link

NeverUsedID commented Nov 5, 2016

Same here. Linux Mint 18 - Nemo 3.0.6.
Nemo search is nice and fast, but don't show content of hidden folders.

Maybe someone can suggest an alternative search as long its not fixed ? Tried Kupfer and Synapse, both a very bad in finding lots files. Nemo seems just right, but need to find files that are in hidden folders.

edit: found "catfish" which works fine on Linux mint. Will use it, until this is fixed.

@NeverUsedID
Copy link

Reproduced on 3.2.2.

@andrewufrank
Copy link

still not fixed - what is so difficult with this? the error occurs still in nemo 3.2.2 on debian stretch (up to date).
use of catfish is a workaround. do not forget to check "hidden files" in catfish!

@NeverUsedID
Copy link

NeverUsedID commented Dec 2, 2017

Reproduced on Nemo 3.6.4. Linux mint 18.3

@mgarcia-org
Copy link

3.8.3 still not fixed.. 👎

@Extarys
Copy link

Extarys commented Sep 7, 2018

3.8.5 still not showing hidden files.

@NikoKrause
Copy link
Member

The fix 8a60207 has been applied after 3.8.5, i.e. it will be available in 3.8.6 (probably not until Mint 19.1).

@Extarys
Copy link

Extarys commented Sep 9, 2018

Thanks! Just saw the commit, my mistake.

@string-areeb
Copy link

Now it shows the hidden files even when show hidden files is turned off

@Extarys
Copy link

Extarys commented Jun 18, 2019

I moved away from Mint to test Manjaro and I now use Gnome Files so I won't be able to test this for a while.

@QmwJlHuSg9pa
Copy link

QmwJlHuSg9pa commented Jul 24, 2023

Not sure if this is a regression or separate bug:

Fedora 37 Silverblue x86_64

With v5.6.4 (Fedora RPM) I definitely notice that I am unable to search hidden files (with "Show Hidden Files" enabled), unless they are directly contained within the current directory. I.e. searching for a hidden file .test-hidden works if the file is within current directory, but the following expected results do not appear: dir/.test-hidden, .dir-hidden/test.

@mtwebster
Copy link
Member

@QmwJlHuSg9pa this works ok for me - do you have 'Search folders recursively' enabled?

image

@QmwJlHuSg9pa
Copy link

QmwJlHuSg9pa commented Jul 24, 2023

Thanks, that was the fix.

Now, there's no way I was going to associate this (horizontally flipped) "Return key" button with "Search recursively". Maybe I had curiously toggled it at some point and forgotten about it? I'm not even sure what the default state is.

Here's why it is unobvious: All(?) other buttons in the basic Nemo experience handle GUI stuff like switching layout state and toggling search bars. It is not expected that the next button in the flow would toggle search parameters, rather than some other part of the GUI.

In this instance, a text label with checkbox would do wonders -- like I mentioned, I strongly associate the current symbol with "Return key". I could imagine the current symbol being a stand-in for "ignore new lines" (at least, if it were applicable to "Search content". Nor have I actually used the "case sensitive" toggle button -- again, this could be a text-labelled checkbox, rather than looking like it might modify some part of the GUI. I understand such changes would cause headaches, and perhaps require the search interface undergoing some sort of visual redesign.

Edit: A basic example of what I mean would be Firefox's built-in page search feature.

Also, I suggest forcing recursive search for every newly opened window, by default. There could be a toggle for this new behaviour in Preferences. Rationale: Recursive search is my expected session default; I can see myself disabling it temporarily via the existing toggle, if I know I want something(s) in the current directory.

@Jeremy7701
Copy link
Contributor

The default setting is to search recursively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests