Separate Filename search results from Content results

[nixsee]

In the latest insider build, a “content:” operator has been implemented and the default search changed to include filename results, as per two other requests (1 and 2). Wonderful!

I’m hoping that a further improvement can be made so that when a search term results in both filename and content matches, the filename results will show up first, followed by the content results. 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:

Filename results going first makes sense because

1. there should generally be far fewer of them.

2. It is quite likely that the content results will be links to the desired filename results

3. The search results are not sorted alphabetically (as shown in picture above)

I also think some sort of separator heading would be useful as well, as shown in this OneNote screenshot from the original feature request:

It would be nice to perhaps even be able to collapse them separately, but that’s not all that necessary.

Thanks for the consideration!

Edit:

To make this very clear, here is a screenshot from a search for “Habit” in the popular IMF vault where you can see that there are many results for both filename and content, all interspersed. I think it would be very beneficial to separate these results. Curiously, the first 20 or so are in alphabetical order, but then are in a haphazard order after reaching “W” - perhaps a topic for another post.

[ryanjamurphy]

Thanks for the well-structured request!

[Klaas]

@nixsee

the filename one gets buried within the results as shown below, where you have to collapse results to identify it

I don’t understand what you mean. In a regular search the filename is shown 1st in bold, and below is the relevant search term highlighted.

Furthermore, each filename/search term combination is clearly separated by a thin horizontal line.

Here’s a screenshot of a random search with the default Obs theme:

So, I don’t see how the filename is “buried” in the uncollapsed situation.

[nixsee]

First, you haven’t done a regular search - you searched for tags. Second, none of the results you’ve shared show “education” in the filename, only the contents.

If you look at the screenshot in my post (it appears that you need to click on it to see the full thing), you’ll see that I was searching for “word”, trying to find the document “Word Count”, which was 9th in the list, after 8 other unsorted filenames that had the word “word” in their text.

I’m sure the algorithm has good reasons for returning the first 8 in that order, but there’s no reason that the filename matches should be mixed in with the file content matches.

[Klaas]

OK, here is a regular search result:

I have no filename with education in it, so I did a search on the basis of a word in a filename. Here is the resullt:

I am sorry to insist, but where is the burial. Maybe I misunderstand you?

and here is a search result

[nixsee]

I’m having trouble seeing how you’re confused by this… Both of your examples are irrelevant to the described issue - the first only returns content matches and the second only returns filename matches.

Either try searching for a word that is in both filenames and file content - “fail” or “the” - , or just look at the example that I have pointed to twice now, where the search term has both filename and content matches.

[Klaas]

Taking search example of terms like “word” or “the” seems curious to me. Those 2 terms are so common that I cannot imagine someone to searching for a term in the same document that is a bit less ubiquitous.

As for your assertion

@nixsee

9th in the list, after 8 other unsorted filenames that had the word “word” in their text

that does not show in your screenshot.

So, I continue to misunderstand your issue. Nevertheless, don’t bother to answer this comment because it seems @ryanjamurphy understands it, and you have good reasons to ask for this feature request. At the end of the day I don’t care what feature requests you put in, I was just intrigued by this one, hence my questions.

Many thanks for your patience, and my apologies for having insisted.

[nixsee]

I used Word (and suggested “the”) arbitrarily so that you could see the effect without any further misunderstanding. Yet, there’s plenty of imaginable scenarios with less common words. An “Index” file, with many files linking to [[Index]] is a practical one, but pretty much any word would qualify: Tomatoes, Canada and Mountain could all very reasonably be part of a filename and file content.

If you would read more carefully, you would see that I said

If you look at the screenshot in my post (it appears that you need to click on it to see the full thing)

I have no idea why it was not showing in full. For clarity’s sake, I have replaced it with a new version that seems to be working. I have also added a new screenshot from an extremely cluttered search in the popular IMF vault.

Putting aside all this misunderstanding, I just don’t see why this would be something to even dispute, especially when I showed a screenshot of a nice and useful implementation of the idea in OneNote. I hope this extra detail is helpful for you understanding where we are coming from.

[rigmarole]

I’m just replying to say that I understand your request, and agree.

Another example. If I am searching for Profit, to find the book “Profit First”, or any content mentions of that book, the note that is actually called “Profit First” shows up at position 10, which does seem strange to me.

The first match is the word “profitability” in content. The next matches are links to Profit First in the content.

Even if I search for "Profit First" with quotes, content matches show up first. And the note called Profit First shows up 6th.

I do not fully agree that “there is no reason that the filename should be mixed in with the content matches”. Sometimes I would just want it all mixed together, and I wouldn’t care where the phrase shows up. BUT I do agree that title matches are typically much more rare, so if they were at the top, they wouldn’t interfere too often.

I would love the option to toggle it on or off, in the same way you can toggle folders at top in a computer’s file system. And I do agree that it seems that the title match should likely have higher search precedence, even when they are mixed.

[Klaas]

@rigmarole: your screenshot makes the issue absolutely clear, even if I have not experienced it myself. A picture, i.e. a good picture, IS worth 1000 words.

I may seem dim-witted to @nixsee, and maybe I am, but I always take the stance that if someone does not understand me I have not been able to communicate the message clearly enough.

This is not the 1st time you clear up others’ message, so I want to thank you for that.

[nixsee]

I don’t think you are dim-witted at all, but there very much seems to be something bizarrely and passive aggressively personal going on here given that at each step of the way you seem to have gone out of your way to ignore and distort what I have said.

I have very much taken the stance that I didn’t communicate clearly enough - I made numerous patient and thorough comments, and even added a further screenshot example, to help with clarification. Moreover, the screenshot of rigmarole that you so highly, and passively aggressively, praised is more or less the exact same as the two that I had already posted and pointed to numerous times.

Moreover, 2 other people have specifically said I communicated all of this very clearly - when I come across a topic that I don’t understand but others do, I always take the stance that I’M the one missing something and humbly work to resolve my ignorance rather than insist from the outset that the other person is not only wrong, but a terrible communicator. And even going so far as to tell them “don’t bother to answer this” during the process.

Unlike rigmarole, who disagreed with part of my post in a respectful and constructive way, none of what you have said has been productive to the topic at hand, much less befitting of a communal, supportive effort. If you have some personal bone to pick with me - as very much seems to be the case - feel free to send me a private message and we can work to resolve it. Otherwise, given that you “don’t care what feature requests [I] put in”, why don’t you just carry on?

[Klaas]

@nixsee: I do not wish to get into polemics with you, esp. after your statement “something bizarrely and passive aggressively personal going on here”. There was nothing aggressive in my questions, nothing that was intended to in any case, or that I am even aware of, no intentional distortions, unless, that is, if asking questions disturbs you. If I don’t get what I consider to be a clear answer I always continue asking. Sorry, that’s me.

I have not meant any harm, I was merely intrigued by your issue, esp. since I had not experienced it myself, as I mentioned to rigmarole. The issue was quite easy to understand once I saw rigmarole’s simple, yet self-explanatory screenshot, compared with your 1st screenshot, which was, to put it mildly, less explanatory. Your replies to my questions did not clear it up either, unfortunately.

Now, continuing this discussion in this vein does not add anything to the thread, even less to the case for your feature request.

So, rather than telling you “don’t bother to answer this” I will say I won’t bother to answer you anymore in this thread, this is the last I have said about it.

If you want to have the last word, since it’s your thread, by all means go ahead if you feel so inclined. Hopefully you don’t mind my saying this.

[jellishero]

+1 Good idea. I’d like this.

[NomarCub]

What you’re looking for was implemented in v0.8.0. There’s a path: and file: search operator now.

[NonVideri]

You have to add an additional “file:” every time you want to search for it to work. I’d love there to be a toggle-able option in the “Sorting” options: “Show filename results first” or something like that.

[nandeshwar]

Hey @NonVideri or anyone else still looking for a quick way to switch between files, they can use QuickSwitcher.

It is accessible by Ctrl/Cmd+O . Cheers!

[blombicar]

@NomarCub

path: and file: search operator now.

Quick switcher is not a solution since it is limited to 10 entries. If the file you’re searching for hasn’t been accessed in a while, it will not appear.

[musings]

I would also appreciate this feature! When using the search function to look for a specific file I often have to scroll down to find the file, even when using the exact title of the file or words within the title to search. Either having files that contain those words shown first in the search results, or having an option to toggle the way that search results are sorted would be great and ease my work flow. Typing “file:” each time works, but is slower and requires me to know and think through in advance if my search is in the file name or the content, and it is often nice to see both types of results at once anyway. Thanks!

[jurassicparkin]

I agree, I’d love this feature!

I pretty much always search with the “file:” prefix as it’s the most useful method for me in my workflow, otherwise I have to scroll down a long list to find what I’m looking for. It’d be really nice to see note-content results below it.
(I like the OneNote screenshot example from OP’s original post).