Search: additional operators and special searches

example search term: bear

  1. @body - with all the linking and tagging, it may be beneficial to target notes where the term is not part of a link, title, or tag

  2. @elink ← term as part of the external link

  3. @wink ← term as part of wiki link

  4. -#*/bear/ ← exclude term as subtag

  5. #*/*bear ← term as compound head (or any non-modifier position) in subtag

  6. -#*/bear ← exclude term in subtag or as subtag modifier

I think some of these are more important than others, like #5.

There are workarounds for some of the tag search issues, like changing the entire tag structure. But, some users may find it undesirable to reorganize tags solely for the purpose of improving search (i.e., compensating for search weak areas)

I’m not sure what the team has planned for additional search features later, so I’m just throwing this out there.

Bear search is good. I think it can be better.

1 Like

I totally agree with you that the search inside the notes list can be improved by: 1. a better filtering by tags and 2. the definition of places where to search. But i do not think that it should be implemented in that way. I understand that some people like to never leave their fingers from the keyboard but it is not user-friendly anymore as it could be. I made here a request for defining the places (title, headings, quotes, code blocks, lists and so on) for search by dropdown menu from searcher. Here a screenshot from inspiring ulysses app that has exaggerated many places (you can even search inside bolded, italic or highlighted text or you can reduce the search just to the caption of an image):

I have several problems with advanced search expressions for that purpose:

  1. I anyway consider them too technical. I prefer a nice and user-friendly ui like in ulysses
  2. There is a logical inconsistency by using also @-expressions for that purpose to define the places where to search. Actually almost all @expression ask for an attribute of a note whereas @title reduces the search place to the title. For example take @code: that expressions searches for notes that contain a code. That means you need another operator than @ to search inside codes. Sorry for bad english. I hope you get what i mean.

In regard to the tag syntax you presented you must admit that the understandability for many if not even most users is hard. My wish for that would be an pop up that shows a tag tree of the tags inside the notes list, means: a tag tree with checkboxes for choosing out and with different states like include and exclude.

For sure a combination of 1. Where to search AND 2. choosing tags inside a tag tree of tags from the whole notes list AND 3. point 1 reduces the tag tree of point 2 would at least for me would be a killer feature. On reddit i also requested that with a reasoning that better should have been placed at the end of the post

(sorry for the language - somehow i was not in the mood to write in english. My main point is to say: i prefer more an friendly ui than search expressions )

by the way: i like your idea to search inside of wiki links a lot :wink:

I can tell you search will be one of the next big areas of improvement for Bear as the editor is for Bear 2.0. It’s a little too early to discuss search core improvements, but we do want to make search less technical in terms of UI and more powerful in terms of features.

Can you please tell me more about why you want to search inside body, links and wiki links?

Can you tell me more about the tag search issues and how 4/5/6 will help?


When searching for a word or phrase, a user may be looking for the source notes and not all the notes linking to the source notes. For example, if I’m looking for notes where I have most of my information about “black bear”, all the notes containing “black bear” in linked mentions or external links are returned requiring me to sift through many notes. Not all notes about black bears may have the phrase in the title of the note.

This issue really shows itself after you’ve used Bear for a while and you have hundreds of resource notes containing many links. Having a way to either a)target the body of the note or b)exclude linked mentions would be helpful.

In the same way, it would be helpful to look for links containing terms. In the image above, you can see a link “[[one bear two]]” in addition to “[[bear one]]” and "[[three bear]]. If all you remember is “bear”, then the latter two are easy to find - but the first one is not easy.

Again, these kind of special searches would help a user filter links during searches.

#4 and #6 - re: the image above, you can already search for the other, “include” version of those. Why not “exclude”? If I can search for #/bear/, then why not -#/bear/?

Also, being able to exclude “bear” as a single subtag would help target notes that have “bear” only as the subtag modifier. Currently, there’s no way to focus a search for #/beartrap, as #/bear returns both #/beartrap and #/bear/

#5 - this one is probably the most needed. Currently, it’s difficult to find notes with the target word as part of the compound head. If you look at the image above, you’ll see the issue. There’s no way to find all your notes containing “bear” in the subtag if it’s the compound head - only the compound modifier. So, for example, if I have taken many notes about bears and tagged them with “whitebear”, “blackbear”, “brownbear”, etc. then it would be helpful to not have to keep an index or recall from memory every type of bear (even if you could, it would be a very long query string). If I can simply search for the word “bear” as the latter part of the subtag (i.e., the compound head) by wildcarding the modifier position, then it would at like a reverse lookup for these types of terms.

Again, these are just suggestions. However, I think as people use Bear more and more they’re going to end up with hundreds or thousands of notes. Many of those notes will contain links and tags. Additional search options related to links and tags would go a long way in helping users focus their searches and reduce the amount of time sifting through notes.

1 Like