searching for notes without a tag

[pfarrelle]

I just discovered your workflow - and I am blown away by how useful and fast it is. Everything worked as expected until I tried a common search strategy of mine that is not available through your workflow.

I have a lot of journal notes in bear, and I often want to search within the journal notes, or more likely exclude them from my search. This is done by searching for -#something

In my case I can exclude all of my journal notes by searching for -#journal_ since all of my journal notes are tagged in the same way. For example, today's journal note is tagged: #journal_2021/01/23.

When I try bs: -#journal_ in your workflow, I turn up only the two notes where I documented this search strategy for myself. In other words searching for -# doesn't exclude tags, but rather searches for text containing -#.

Hope this makes sense.

Thanks again for this wonderful contribution.

[drgrib]

Interesting. I just received an identical request in #37. As I said there, this isn't something I've ever needed to do, so I can't guarantee I'll have time to add the feature personally.

If you or anyone else ends up wanting to give an update to the code a try, though, I could review and test the change, merging it in if it is stable and functional. There have been contributors in the past who have fixed bugs and added features to the workflow.

[pfarrelle]

I understand that you don't have the need or the time. Unfortunately I don't know the go language. In fact, I didn't even know that it existed before finding your code. However, I did peruse your code on GitHub and I think the relevant code is in the func ParseQuery in the core.go module. Lines 96-115. In that module you seem to differentiate between word searches and tag searches. Specifically there is a switch statement (lines 104-105)     switch {     case strings.HasPrefix(e, "#"):         query.Tags = append(query.Tags, e)     default:         words = append(words, e)     } Where you differentiate between a word search and a tag search based on the presence of "#". Again I don't read go, but perhaps allowing (-)# instead of # would solve the problem. It is the same x-callback url to bear just with or without the leading "-" sign. Hope this might spur your interest since it seems a clean change. Thanks, Paul

…

On Jan 25, 2021, 3:09 PM -0800, Chris Redford ***@***.***>, wrote: Interesting. I just received an identical request in #37. As I said there, this isn't something I've ever needed to do, so I can't guarantee I'll have time to add the feature personally. If you or anyone else ends up wanting to give an update to the code a try, though, I could review and test the change, merging it in if it is stable and functional. There have been contributors in the past who have fixed bugs and added features to the workflow. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[drgrib]

That would be part (but not all) of the syntax change required, yes. But the deeper and more difficult change would be creating and using a new SQL tag query:
https://github.com/drgrib/alfred-bear/blob/master/db/db.go#L60-L87

The query and the code that calls it are already complicated and would need to be changed in a way that doesn't break the current functionality. While it may not be obvious at first glance, this is a pretty major feature to add. Because of that, I personally won't have time for it any time soon, possibly ever, especially because I have no need for the feature myself.

[mjknght]

I remain hugely grateful for this workflow! In fact @drgrib, I'd gladly tip for this if there was a PayPal link.

Ridiculous though this may sound, I use a couple of other workflows with Bear – features overlap somewhat but all are handy for different purposes. For the use case described above, it might be useful to glance at BearHunter – this is the workflow I'd use (albeit only very occasionally) when I need search operators of the sort mentioned here.

[drgrib]

Much appreciated @mjknght, both for the gratitude and the advice for alternatives. I should probably look into adding tip link for interested parties. I've felt similarly for other works I've seen on GitHub.

[pfarrelle]

Thanks for the suggestion  @mjknght, I will look into it. However, let me say one more time how much I'm appreciating your workflow @drgrib - thanks again for sharing it!

…

On Jan 28, 2021, 8:58 AM -0800, Chris Redford ***@***.***>, wrote: Much appreciated @mjknght, both for the gratitude and the advice for alternatives. I should probably look into adding tip link for interested parties. I've felt similarly for other works I've seen on GitHub. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[drgrib]

Thanks @pfarrelle!