Search: additional operators and special searches

Beta Panda Feedback
1

example search term: bear

@link-2
@link-22000×1414 143 KB

  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
2

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):

Bildschirmfoto 2022-11-11 um 21.14.04
Bildschirmfoto 2022-11-11 um 21.14.04378×763 80.7 KB

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 )

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

3

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?

2 Likes
4

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
5

I would like to suggest some additional potential search features

  1. Searching for notes with a tag and no other tags.
    * For example, if I want to search for a note with #tag1 but not #tag2 #tag3 … #tag10, I want to exclude #tag2 through #tag10 without having the type them all

  2. Searching for notes with a specific number of tags, or number of additional tags

    • For example, a search for notes with #tag1 + 1 other tag,
    • where “1 other tag” can be any 1 other tag (or any 1 other tag from a specified list/group of tags)

For #1, the idea is that, if you want notes with only a certain tag it doesn’t make sense to type an exclusion for all the other tags that might be paired wit it

  • Basically, I am suggesting an easier way to search for notes with a specific tag (or 2… or 3 specific tags) and excluding all tags except those.

For #2, I don’t remember why I wanted this, but there was a time I dd… The idea of tag groups/lists for searching/filtering might be useful though?

Also, I want to note I don’t like the Ulysses image shown above. Seems inelegant and with too many options in the menu.

6

You can type it once and save it as an X-Callback-URL search action. Not all tags have numbers so I’m not sure how a special “range” search option would apply in most cases.

Manually, specifying a “-” prefix is as easy as it gets. If there was a special search option it’d likely be more characters than one.

It sounds like using nested tags solves other issues here.

7

I like this as I myself had earlier asked for a similar feature, that is, tag filtering.
For an app like Bear whose sole organising feature is to use tags, it’s really sad that you can’t select multiple tags from some sort of list, exclude a few you don’t want to be included, and the resulting note list will be filtered to contain notes exactly with that combination and exclusion of tags you selected.
It’s really difficult to type out tags and special search syntax to do a quick search.
I hope the devs soon come up with this kind of a solution.

8

2.0 (10784) has a new special search - @pinned. This seems to be based on one, niche use case involving a Shorcut workflow just recently. Maybe there’s another use case?

This is a strange priority of search and tag improvements. I mean, any improvement in search is welcome but given the other search needs I listed in the OP months ago (also see here for a request for finding unlinked notes), I don’t understand this one.

9

Hi @brian, I see that is frustrating to have @pinned implemented quickly to solve my “niche” use case for shortcuts when you have many improvements you’d like to see too. Especially since you’ve spent a good deal of time and work to detail out the search improvements you’re advocating for here. I do want to offer that there might be a simple explanation here: @pinned might have been very easy to implement. (“Low hanging fruit” if you will.) That might be because implementing @pinned was simple since pinned is a boolean column already available in the sqlite DB. There is a rule in software development: features are unimplemented by default.

I hope you don’t take it personally, I think the bear team is working super hard to turn out all the features and improvements we want. They’ve done an excellent job with bear 2 so far, and it’s only going to keep getting better! I look forward to hear what the bear teams improvements to address the search problems here as well, since I also face some of them, but I also can see how the work might not be trivial to implement.

In any case, thanks for advocating for me and other bear users with your well-thought-out feature requests!

1 Like
10

I assumed the reason for implementing @pinned was because it was easy/quick to implement, but the developers have not communicated that reason (communication is a requirement specified in your linked article). I think this communication is important because it lets users know how they are prioritizing features or even what features work properly.

Also, your article doesn’t discuss the number of users affected to justify the development of a feature. Over the past year, it has become clear what’s most important: feature prioritization for the minority of users (usually the most vocal) over features that would benefit the majority of users. I just wished this was communicated more so that I (and others) know if they’re wasting their time posting here.

11

I have implemented @pinned in my free time because I wanted a widget with all my pinned notes (I have never thought about that). It took me half an hour testing included and nobody else was involved in the development. This is not exactly a feature that requires a lot of prioritization honestly.

3 Likes
12

Good to know. I’ll stick to suggesting features I think the devs will use and can be easily done in someone’s free time :slight_smile:

But, seriously. How are you using @pinned? If you’re going to add a special search operator it would help if your use case (in addition to @cipher) was also posted so that others can benefit.

By the way, the larger point I was trying to make is that It’s not just about @pinned - it’s about many other features that cater to the few and not the many. This is clearly a misperceived requirement on my part.

13

I’ve just shared my shortcut in the original post for @pinned: [Resolved] [Search] Add a @pinned to only search pinned notes - #2 by cipher

1 Like
14

To answer on how @trix180 was describing their use for pinned searches using an iOS widget:

  1. Create a search widget

    IMG_4200
    IMG_42001179×651 43.4 KB

  2. Profit

    IMG_4202
    IMG_42021179×636 37.3 KB

15

Thanks. I understood your use of @pinned, just not @trix180 due to wanting…