Selecting "Hide Subtag Notes" will hide notes that contain "tag" and "tag/subtag"

If my note has 2 tags: “#tag” and “#tag/subtag”, and I select the Hide Subtag Notes option, then opening “#tag” will not show this note, as it contains a subtag.

However, in this case since the note contains the root level “#tag” as well, I think it also makes sense to show this note.

Is this behavior by design?

It is by design. The database in bear cannot be aware how many tags of the same nested family re inside a note. The database would need a rewrite to address these. That is the only serious issue i have with bear as it makes reasonable user scenarios impossible and at least in my opinion goes against expectations

See here!

I see. This definitely feels odd, and I guess I will try to structure my notes in a way that I don’t need to use the “Hide Subtag Notes” view, or search for parent level tags.

In general, clicking on a tag, and seeing that note disappear away from the view does not feel right.

Yes, it indeed feels odd, but it is due to the limitation of the database. To my surprise the devs additionally do not consider that as odd behaviour although it furthermore could come to irritating behaviour f.e. if you tag a note and it immediately disappears. That problem actually just occurs if multiple tags from the same nested family appear in the same note

1 Like

Agreed, I actually thought I had lost a note before trying to figure this out.

Hopefully this will get addressed at some point in the future, at least as an option.

1 Like


I do not intend to bug as i also know that this point is related to the limitations of the database which doesn’t know about single tags from a nested family which can appear multiple times in one single note. I just hope that you will acknowledge that this behaviour is by far not what a user would expect. And this post from @dharam proves that. I would go so far that every user that uses multiple tags from the same family will be confused. There are so far no much complaints because probably the most users use generally one tag from one family.

When you will start improving the search functionality i hope you will consider a rewrite of the database not just for that issue but also for meaningful features in other areas: The first that comes in my mind is f.e. the ability to search for tags inside a note via inline search for a single note which requires to be aware of single tags from one family

1 Like

Hello folks,

as already stated this behavior is by design and we have no plans to change it.

#tag/subtag adds both #tag and #tag/subtag to the note, this is correct and what we want. Even if that wouldn’t be the case “Hide Subtag Notes” would still hide the note as it’s contained by a subtag, so it won’t do any good for your use case.

“Hide Subtag Notes” was designed to mimic a folder structure, and you can’t have the same note in both folders.

I’m sorry to have to write this, but no, we still think that the current behavior is the most simple and expected.



@Matteo, yes after learning that a #tag/subtag means a #tag and a #tag/subtag both, I can understand how the current behavior works.

Maybe though, if I am tying inside a note with #tag, and then I type #tag/subtag it would feel better if the note does not disappear. And there is no way to get back to that note easily. We could instead switch to the “Notes” view, and keep that note still in editing mode.

Either ways, I have changed my notes structure now after understanding this :slight_smile:

1 Like

Yes, this is an improvement we should add :slight_smile:


It is an improvement in the sense that the real issue is not solved but its side effects are just adressed. Sorry, if i am annoying but i deeply believe that the current behaviour cannot be what is expected. Whoever clicks on a tag expects that all notes with this tag appear in the notes list. However, if you click on a tag #a/b, not all notes with this tag will appear because those that at the same time contain #a/b/c are filtered out. I am firmly convinced that the focus of a user who clicks a tag lies on that tag and not on the subtags. Calling it “folder mode” was just an praraphrasing for the wish that the notes list of a parent tag doesn’t hold also the cumulation of its subtag. But a note with multiple tags from the same family is hybrid, it is both. In a folder system the same file can appear as (hard) copy at different places.

Actually i wouldn’t care IF bear would just allow to set tag related to the whole note like many other apps which doesn’t allow to set a tag on an arbitrary place inside the editor. So it makes sense to decide for either #a or #a/b or #a/b/c. But bear is not that app, it allows me to write a tag wherever i want, in the title, under the title, in any paragraph or under any heading i like. The wish to find those single tags is a reasonable wish in my eyes. And with finding i don’t mean only in the notes list, but also in the note search ( i mean cycling through the search results for a special tag). As bear is constructed around tags it will be a further improvement of its core feature in many regards. That was my hope, that if you want to improve anytime the search capitabilities you are also going to reconsider.

The question in regard to what the user expect is actually:

When inside a #a/b/c/d tag tree from sidebar clicks on b

he expects that ALL notes that contain #a/b are shown and ALL notes that do NOT contain #a/b are hidden


he expects that SOME notes with #a/b are shown but those with #a/b that also contain #a/b/c are filtered out

Ok, i will shut up now :wink:

I am sort of unconvinced. What is the use case of having a note both in the child tag and the parent tag?

We are talking about a note f.e. that contain both tags: #father and #father/son

If you like call it a hybrid note in regard to a tags from same family. I expect - when hide subtags is activated- that this note is also shown in notes list when I click father in tag tree because #father is a tag inside this note. Wouldn‘t you either?

So they are shown in both tags because they contain both tags

@Eleanor, it is possible for a note to share some properties of a child and a parent tag.

Either ways, the reason why I asked this is because Gmail’s nested tags work in this manner, and so I expected that for Bear as well.

I don’t want to debate too much on whether the decision is right or wrong, as Bear considers this to be the expected behavior. And maybe that is the case, since I’m a very new user to Bear and was probably not using it correctly.

Yes I understand what mechanism you expect to happen, but I don’t understand what use case it has. I’m not saying either is wrong. Just was curious what circumstances would use this scenario.

The use case is simple. I use bears possibility to tag the note or a text at different parts, not only under the title but also under different headings.

To give you an example which I also used in the origin thread:

Let‘s say I have a bigger note or text about social politics. I would tag it with #socialpolitics directly under the title as long as the introductions contains common messages to socialpolitics. Some subchapters however I would tag with #socialpolitics/germany or even more specified #socialpolitics/germany/healthinsurance.

As you see I am not talking about short atomic notes but about larger evergreen notes if not shorter text/prosa. With the current behaviour I am not able to list all notes that contain a special tag. Either I have to take a cumulative list with subtags notes or an incomplete list.

For sure that is an user scenario that goes beyond simple tagging of short notes. But it is bear who makes possible heavy tagging all across the note without making possible a simple task: to show all notes with a special tag and to hide all that do not contain that tag.

Your question actually is why should someone use multiple tags from same family inside one note. But if he uses them then it is a logical consequence that he also expects that he gets complete lists of each single tag

Ah I see. I personally stopped using that approach when I realised tagging in the middle of the note does not necessarily make you be able to skip to that section of the note easily when you open the note with that tag. But yes, it makes sense now.

That would be like as a dream becomes true if that would be possible one day. F.e. to cycle through one special tag inside the editor. Or to have a listing of all containing (sub)tags inside a note or inside a notes list. Bear is based on tags and there is so much potential that is not exhausted. I still keep hoping. There must be some improvements left for bear 3 :smiley:

The “correct” approach can be subjective; it often hinges on how someone arranges their workflow. For some, Bear’s existing features may align perfectly with their needs, while for others, these features may cause challenges or inefficiencies.

Regardless of what Bear’s final decision is, an improved introduction to the software would be beneficial. This should clearly guide users on how to use the current features, what they offer, and what they do not. Discussing its limitations is not necessarily a disadvantage; it can help users tailor their workflows in Bear to maximize productivity.

In the context of “hide subtag notes”, I think of the following:

  • What can be clearer?
    • #parent/child actually means adding #parent and #parent/child to the note behind the scene.
  • What is possible with the tagging system and “hide subtag notes”?
    • Mimicking what one would expect in a traditional folder/file system.
  • What it cannot achieve?
    • With “hide subtag notes” toggled on, when you select #parent tag, you won’t see any note containing #parent/... even if the note also contains #parent.

If several copies of the same file exist in several folder I would expect that the finder shows me in each of those folders that file :wink:

Why someone would want that when clicking on parent?

But we shouldn‘t talk about expectations. As the devs explained that behaviour is due to the limitation of the database that as the same offers a simple and effective handling for most use cases. Just not for that one task. It is not necessary to add a reason after the fact that has nothing to do with the actual reason. I consider the decision of the devs in regards to developing costs as completely rational and economical. I just have a problem with the reasoning that it is something that most expect. To remain in the folder metaphor: if a file is in the folder, I want to see that file as content of the folder. If it is copied into more than one folder, I nevertheless want to see it in each folder. There is no logic to prefer one folder over another. The function was not created to match the functions name „hide subtags“ but otherwise: the function is determined by the capitabiöities of the database

Yes I respect that everyone thinks differently and that’s why I said earlier, that what feels logical and correct is subjective.

I think you’ve done a great job clearly explaining your reasoning, workflow, and some use cases. And I’m sure that will help the dev team to evaluate should they wish to reiterate on this subject.

What you think is logical doesn’t seem to be what the devs think is desired, as they’ve also stated that the current behavior is also what they “want”, and not just due to technical limitation. Nevertheless, this doesn’t mean you are less right or your workflow is less logical. It again shows the diversity in the world. And we should celebrate this! Cheers.

By the way, names, conventions, and stereotypical expectations, are useful most of the times, but also can be confusing at times. That’s where I think a clearer onboarding material or FAQ could help guide the users understand what the features can and cannot do.

1 Like