Make default search function look in all fields - filename, content, tags, etc

The recent upgrades to Search are fantastic, but as per a recent discussion on the Insiders’ Discord group, it would be great if the default search function returns not just results from the contents of files, but filenames and tags as well. The reality is that we generally don’t keep track of what is what, thus are using search to find an idea wherever it may be. Without this, Obsidian becomes very cumbersome (and perhaps even impossible) to use.

Perhaps a way to present the results would be to implement something like OneNote does - separating its search results by Title and Content. Tags or other parameters could have their own section as well, each perhaps with an arrow to collapse them.

15 Likes

Being able to include the file names in the searches, with a “contain”: operator would immensely help my workflow. Hoping the devs would consider this!

I support this – the default search action should be to search all content, including the file name (since the file name functions as the title of the content).

Giving greater weight to matches in the title or in tags would be another nice improvement, but that’s less important than just finding matches in titles.

A tag: operator would be a big improvement. It’s been asked for before in a roundabout way, and I would love to have fast constant-time tag lookups as opposed to the slow content searches that happen when you search for a tag now.

1 Like

Only tag names and counts are cache, the positions are not, due to how the parser works, so it’s not as low hanging as it seems.

@nixsee: appreciate the feature request, would prefer the feature request to be specific and atomic (see the third paragraph in the new post template). That way people who are interested in a subset of your ideas are more likely to notice your post, and it’s easier for us to move implemented features into the archived list, rather than having to go through the list again and not being able to archive it because not all features mentioned are implemented.

1 Like

Thanks! I’ve edited the title and description to focus on the default search function.

I created a new feature request for new operators here

3 Likes

This is definitely a great idea.

For example, it is quite frustrating to be unable to locate a note even when typing its exact name, because the note name is only present in the filename and not in the content. This specific use case (filename vs note name) is somewhat related to this feature request: Use H1 or front-matter title instead of or in addition to filename as display name.

1 Like

I support this as I don’t see the downside. The use of operators is to leverage search granularity so searching without operators should be broader by default, no?

2 Likes

Please implement this, guys. Default search behavior should be searching everywhere. Operators should be modifying the default behavior, not vice versa.

2 Likes

This feature request is likely to be implemented. No ETAs.

2 Likes

I see this has been implemented in the latest insider build, along with this request for a “content:” operator. Wonderful!

I’m hoping that a further improvement can be made to have the filename results show up first, following by the content ones. It doesn’t make much sense to mix the two, as the filename one gets buried within the results as shown below, where you have to collapse results to identify it:

I think some sort of separator would be useful as well, as shown in the OneNote screenshot in the original post, perhaps even being able to collapse them separately. Filename results going first makes sense because there should generally be far fewer of them.

Thanks for the consideration!

1 Like

@nixsee to be more atomic. I am going to close this. Post your follow up in a new feature request.

For anyone subscribed here who is interested, a new request has been opened for Separating Filename search results from Content results

Feel free to lend your support there!

2 Likes