Strange sorting relevance in Note List Search


There’s something strange about the search in Bear’s note list: found notes are sorted partly by relevance, partly by modification date, and most importantly the relevance is set in stone by the very first shortest match in the title (match = segment + space after it), while other matches in the title after that first match do not add weight and are equated to matches in the regular text. The program first sorts found notes by the first match in the title, and then by date of modification, considering all other matches in the title as irrelevant.

To make it clearer, let me demonstrate how relevant search works in iA Writer, another great markdown app:

Another great example of relevant search is macOS Spotlight:

This search relevance is simple, intuitive and so powerful: notes that match the search query are sorted prioritized by the text found in the titles, i.e. according to the principle “matched in titles is more significant than matched elsewhere”. Notes with matches in the title get to the very top of the search list, and notes with matches in the body follow below. Thus, the notes you are looking for will most likely be at the very top, which saves a lot of time (as long as you give your notes meaningful titles).

Now let’s compare it with Bear’s search, or, to be more precise, how it sorts the notes found (the same sample notes are used in the video).

1) One match in the title gives us the same sort by relevance:

2) Two or more matches in the title are not treated as one whole and do not add up their weights, and sorting by relevance occurs only by the first match, which in the example below will be present in the titles of all notes, thus making such sorting useless:

In the video above, we see that the found notes are sorted not so much by relevance but rather by date modified, which is why the note you are looking for can be located anywhere in the note list.

You can use the search token @title to get rid of matches in the body of the notes and achieve something similar to the relevant search, but this is far from ideal as it prevents your from making your searches more specific. For example, at the very end of my notes, I often put this tricky thing:

<!--// 🔎S34RCH_H3LP3R
synonymous word/phrase/sentence A • synonymous word/phrase/sentence B • ... //-->

The use of the mentioned workaround makes this alias section meaningless. Moreover, typing this token every time is not very practical and quite tedious, especially on mobile devices. I’ve tried using text shortcuts (ttt@title), but it’s not very convenient and doesn’t solve the problem in general.

The same search behaviour also exists in Bear 1. Maybe this is a hidden bug that doesn’t really bother anyone but me :thinking::sweat_smile::joy:

So, dear Shiny Frog, I know this is not the right time to ask you about this as you are currently hard at work polishing the existing features, but could you please take this feedback into account and improve search sometime in the future :slightly_smiling_face::pray: (Yep, I’m a total fan of the really good search… *__*)


This is very interesting. Prioritizing notes with multiple matches in the title sounds correct to me. There are a lot of fine prints in this sorting algorithm we need eventually need to sort out but I think it might work for Bear.

Thanks. I’ll make sure to check this when we’ll tackle search enanchements.

1 Like