I believe that it is known that search in Bear, from Shortcuts, isn’t accurate under certain circumstances where the number of notes matching a search term exceeds some limit.
In my experience when the (matching) note count is large enough, Bear search will fail in one of two ways. It will either limit the returned notes to 300, or it will throw an error.
For example, I currently have 5499 notes and 593 in the top level tag: resource>computer
If I try to access these 593 notes from shortcuts in one of three ways, only one gives the correct answer:
-
Search notes containing with parameter: #resource>computer#
→ 300
-
Search tags containing with parameter: resource>computer
→ “Could not run Search tags; there was a problem communicating with the app.”
-
Get the tag with parameter: resource>computer
→ 593
Only number 3 is accurate.
I had thought earlier that the total number of notes in my database might be the problem. I had also thought that it might be specific to the nature of my notes, but after lots of experimenting, I now know that the problem is dependent on the search criterion itself and the number of notes that match that criterion, rather than the straight note total.
If I focus the search to a smaller number of notes by changing the search term from:
resource>computer → resource>computer/dev>, where there are only 36 tags in resource>computer/dev>* and those tags contain 282 notes.
This scenario still causes a problem for:
Search tags containing with parameter: resource>computer/dev>
→ “Could not run Search tags; there was a problem communicating with the app.”
I presume the root cause is that the tags are not accessed directly, but rather the notes are accessed to get the tags, and there are 593 notes in tag resource/computer of which 282 are in sub tags beginning with dev>. I think the 593 number is still breaking this search.
Notes:
-
I can get method 2 to work if I work within a different part of the tag structure with only a handful of notes.
-
I can successfully search in the bear app itself, these issues only relate to search via the Shortcuts app.
The reason for this note is twofold.
-
To report my results which may be useful for the developers. Ideally they could find a way to address the search problem despite the limitations imposed by the shortcuts environment.
-
To request a simple way to get the list of tags in bear at a particular node in the hierarchy.
- I can
search tags containing but this may match other notes that match the criterion and are either not tags, or not the desired tags.
- I can access the tags via x-callback url, and parse the list myself, but it would be helpful to get all child tags for a specified parent tag, with the root as an option.
Thanks for reading…
The main problem we have with intent (Shortcuts) search is the 30Mb memory limitation along with providing the same search results provided in-app.
What I’m pretty sure is happening here is
- The search is performed on all your notes and the results are limited to 300 to avoid memory issues. This is a limitation we have to impose to avoid being killed by the OS.
- Memory has exceeded 30Mb and the Shortcut extension is killed. We should probably handle better this case but we will be able to provide the expected result for your library.
- Search is not performed because the tag’s notes are fetched using the database relation.
We have improved intent search a lot in the last months with users’ (mostly yours) feedback but the memory limit is something we can’t overcome regardless of the time we spend working on the issue. The 300 results limit is something we have in our code and, to be honest, is not a great solution but it works for most of the use cases.
I’m afraid I have come to the conclusion intents are not the right tool for performing a search on libraries like yours. We hope the limitation will be extended to 60Mb at some point but the problem will persist in some scenarios.
XURLs are performed in-app so bypass the memory limit and can be a solution to your problem.
Thanks for the quick reply. I see two nuggets in your response that might be useful.
The first:
Search is not performed because the tag’s notes are fetched using the database relation.
I inferred this from my test yesterday, since it was the only method that was successful. However, I hadn’t realized it earlier.
I maintain my own database of tag names for a large and very structured part of my library, so I can use this approach moving forward to get notes in those tags.
The second:
XURLs are performed in-app so bypass the memory limit and can be a solution to your problem.
This is news to me and I will definitely pursue this.
Thanks for the insights.
I may have spoken too soon.
I was excited to be able to use a known tag to get those notes. I had assumed that I could then search within those notes to accomplish the big search in two steps with a much higher chance of not hitting the 30Mb intent limit.
However, it appears that search always targets my whole library, so my supposed approach of searching the notes returned from a specific tag isn’t supported.
If my proposed strategy would indeed reduce the memory required by searching in a subset of the complete library, then I would like to request that the search notes containing action be generalized to search in a list of notes as input.
Certainly off-topic here and sorry for jumping in but 5499 notes is kinda crazy, that’s a lot 
Can you tell how you use bear and what kind of notes you take ? Just how’s your bear notes workflow, I am really curious. Thanks.
I use Bear in conjunction with DEVONthink to manage every aspect of my life, which includes a business and multiple properties, and is arguably more complex than I would like.
The PDFs and other files typically live in DEVONthink but the notes are all in Bear. There is strong bi-directional linking between the two, so that I can work without friction in the two apps simultaneously. Writing is much more pleasant in Bear and DEVONthink eats up all my files with ease. I migrated from Evernote to DEVONthink a few years ago.
Of those 5k notes, 3300 are daily journal notes. I have used other apps in the past (workflowy, Dynalist) but now all my journal notes from 2016 are in Bear. I don’t access them all the time, but they are full of nuggets for projects and maintenance that I do today.
On my Mac, I rely heavily on Alfred to access my DEVONthink and Bear notes. I am trying to emulate this behavior in iOS using shortcuts.
I am currently trying to distill the non-journal notes into fewer notes, since many, if not most, are single bookmarks to articles on the web. This is a daunting task and I am building scaffolding in shortcuts, including search, to help.
Hope this is clear.
1 Like