What were you doing:
I choosed in preview settings for notes list: “Hide subtags”. I created a note and tagged it with #firstlevel. Then i created a second note and tagged it with #firstlevel/secondlevel. Then i went back to first note and added the tag #firstlevel/secondlevel.
What feature did you use:
Tagging of notes and preview settings
What happened:
After tagging the second note it disappeared from the notes list for tag #firstlevel although it contains that tag
What did you expect to happen:
To see it in the notes list
Edit: you don’t have to create a second note, just add a tag and then add the same tag with a subtag. Above i described the random way how i discovered the bug
Edit2: i fear that this could even be a feature. Bear 2 removes from notes list aggressively (if option “hide subtags” is enabled) not only the note that contains just the subtag but also the notes with the parent tag if an additional subtag is present? If that’s a feature then: please change that
Edit3: I think it is not a feature since it happens only from level 1 to 2, but not on a level 2 to 3
Yes, this is how Hide subtags notes is currently implemented: One child tag excludes a note from being viewed by the parent tag (I see this happening also for levels > 2). In our minds, this specific feature is for people who want tags to behave more like folders, so we applied a rule that forbids notes to appear on both the father and the son.
Why do you want this preview option and one note to appear in two places in the tags hierarchy? Or, in other terms, what’s your use case for this?
The desired behaviour reflects the basic principle that for a choosen tag in sidebar all notes are listed that contain the tag in the note. As you have multiple tags so you have multiple appearances of the note in the tag tree hierarchy. In my opinion hiding subtags and mimic folders are different approaches. My expectation is not to see the notes in higher levels of the nested tags if these tags do not exist. But they exist. For me that is confusing and would make imposssible what i would like to have and is important. I was so excited abot “Hide subtags” but in such an implementation it is useless
To show one use case: i tag my notes or texts hierarchically. F.e. under the title i would place the tag #social_policy and under subheadings something like #social_policy/germany or #social_policy/france. The first one is more common and represents the topic of the whole note, the latter one represents the topic of subsections. Now it can happen that i use a concrete tag like #social_policy/germany in a note that at highest abstract level is represented by another topic that doesn’t belong to social policy. The concrete tag #social_policy/germany helps me to find all sections or even paragraphs which are related to germanies social policy. But unfortunately i loose the opprtunity to list my notes by its most abstract tags.
To anser your question shortly: Because i tag different places inside a not. If i do not want a note to appear in parent tag i just do not use the parent tag. Why should I? But if i use it then the expectation to find it via the tag tree is reasonable
My understanding is you don’t want to Hide subtags notes but rather Hide subtags notes with the exception of those notes that also report the current tag which is a really hard concept to communicate with users and a very bad menu label.
Given your example, why do you want this preview option to be active at all? If you use the subtags just to tag sections of the note and you want to see those in the parent note seems to me you want the standard behavior. Do you want some notes to appear in the parent tag list and some don’t?
What is hard to communicate? The feature? The name however is hard to communicate In my eyes it is hard to communicate that i click on a tag in the tag tree and some notes that contain exactly this tag are not listed. Why would an user not expect to see these notes?
Because i do not want notes to be listed that doesn’t contain the tag i’ve chosen in the tag tree. I just want to see all notes that contain the chosen tag.
That is reverse logic. A note has multiple tags. And in tag tree i am looking for one special tag. If they contain further tags i do not mind. But if i’ve choosen #father and in a certain note ONLY #father/son resides then i want the note to disappear. Your point of view or logic refers to what to hide, mine on the other hand refers to what to see. In that sense a name like “Show only parent tags” (that’s a better name than yours ) would be better for what i want to have. Take that as a feature request I really believe that this feature do not represent an excentric wish
No, that’s not what i want. I do not want to see these notes because of those child tags. They are not interesting me. I want to see all notes with the parent tag and just these notes are interesting me. And they interest me because of this parent tag.
In my example above that means: i want to show all the notes which topic is about social policy in common. And currently that is not possible. I am sure when a user clicks a tag in the tag tree he thinks about what he wants to see. And what else does a user should think about if not the tag he has choosen?
Well in my opinion, because the feature is called Hide subtags notes and it’s meant to give something that mimics folders (so a note is not expected to show more than 1 time in the hierarchy), what they want to see is any note that has the selected tag but not any subtags.
Considering your use case what you want is not right or wrong, it’s just not what we wanted or what the label suggests. I guess we’ll see if other people want something different here.
I don’t agree Show only parent tag notes or rather Show only selected tag notes is clearly stating what this functionality does.
I think there is a bit of confusion about how tags work:
a note with the text #tag1/tag2 is tagged with both #tag1 and #tag1/tag2, adding another #tag1 somewhere else in the note doesn’t have any effect on the number or kind of tags.
is equivalent (in terms of tags) to a note with the text:
#firstlevel
#firstlevel/secondlevel
Tags are metadata that doesn’t have much information and they don’t carry the number of occurrences inside a note, just that the note is tagged with one of them. What you’re trying to accomplish is just not possible with the current database structure.
While I understand what you’re trying to accomplish, is not what the Hide subtags was meant to be used, the wording is precise and all notes that have a subtag of the tag you’re looking at will be hidden.
This is not something that we can change without making the database structure way more complex, and while your use case is neither good nor bad it’s not what we were asked in numerous feedbacks (mimic a folder structure).
We’ll wait to see if there are more users that were expecting something different, but due to the db structure, this is unlikely to change.
I tend to agree with OP but don’t really have a strong preference on this.
To elaborate: in a folder structure, I can make a copy of a file and move it to another folder. So if I add the parent tag explicitly as a second tag, I believe the note should be shown in this tag’s view at all times.
I never understood that request as mimicing a folder structure. Actually you cannot mimic folders with the current implementation because the same note still would appear in different lists, f.e. in each subtag of the same level. A folder structure is only achievable with folders. Now the feature offers a mix of both that at least me finds highly confusing as it goes against the expectation to click on a tag to show notes with that tag. Apart from that it makes impossible a good usage of bear as pkm-app where you can tag different parts of the note/text with multiple tags even from the same family (father/son/grandson). Actually it do not make sense at all to tag a note with #welcome and #welcome/beginning like in bear welcome notes. That correspondents to matteos comment:
I wasn‘t aware that the search expressions in bear work the same since I do not use them
I listed from memory the most active users to hear their opinion. I also have no issue with the feature as long as a single note do NOT contain the parent tag AND a child tag at the same time: in that case everything works as expected. With these notes the issue - i am talking about - cannot appear. But when father and son sits together at the table, the father is not shown although in the tag tree it was chosen to show the father. I just want the son to disappear when he sits without his father at the table
I am not an aggressive user of tags. I once tried to segment my notes paragraph using tags but soon quickly realised that is not how it is supposed to be used and quickly moved on. Although your suggestion is what I may expect I don’t necessarily mind either, especially if it is a matter of rewriting how the database work as a whole.
Even at the risk to appear as a whining guy i have to pick up again this topic. I am too passionate about it. Let me start with two videos that show some side effects:
Video 1 shows how note and content of notes list disappear after clicking a tag inside the note whereas video 2 shows how note and content of notes list disappear after adding a tag. I assume that this behaviour is unexpected to most users even it is the logical consequence of how the “hide subtags”-feature is implemented inside the current database model.
@trix180, let me pick up your argument that “hide subtags” should mimic a folder organisation of notes. I have to say that your argument is not valid. A note (as long as it can contain multiple tags even from the same family) is placed in more than one “folder” (imagine that note as copy or think about hardlinks) and therefore it is justified to expect that all notes containing a (parent) tag are shown even with “hide subtags” enabled, because it indeed it is part of folders content.
As long as a user do not write multiple tags from the same family inside one note he will not remark any unexpected behaviour. Probably not many users will use multiple tags from same family, especially if you write short or atomic notes. The longer the note the higher the probability that you will use multiple tags (father and son and grandson) inside one note. And then the user will experience that actually a simple task (“show me all notes that contain a special tag and hide all that do not contain that tag”) is not possible.
I understand how the database works after matteo explained it. The question is now: is it worth the development cost to rewrite it. I gave an example how i would use a proper implementation of “hide subtags”. And i believe there are more scenarios there it is useful to use multiple tags of same family: take as example a review of a book there multiple members is a nested tag family are used. In the next days i am going to write a proposal about "thinking nested tags to the end“ and how a less limited database would enable many other useful features and scenarios.
We know hide subtags is not the same as folders but this specific feature is built for people wanting folders, but this is hardly the main issue.
The main point seems to be you want to give #a/b a different interpretation compared to what Bear currently does and I’m more concerned bout breaking users’ expectations. If a note tagged #a/b is not equal to a note tagged #a#a/b asking the notes tagged #a should not return the note in question even if hide subtags is off, and I don’t think we’ll ever want that.
Yes, but i think i have a valid point: i just want a listing of all notes that have one special tag. And bear is not able to list all these notes(neither from tree with “hide-subtags”-feature nor with advanced search expressions) because some of them have nested subtags. That list of notes is not an excentric wish but an understandable one
The tag search in notes list works same way: notes with subtags are hidden even if they contain the parent tag. Due to multiple tagging such notes are hybrid, they have both attributes. And therefore: wanting something like a folder mode includes listing all content from a folder
I think there is no reason to be concerned about that. In this thread three users gave their short comment: one doesn’t care and the both other expect the same like me
I do not understand that sentence. Can you phrase it in other words?
My additional argument in the last post was to show with the two videos how many side effects you have which i cannot imagine to be acceptable
For some aspects of the apps we can follow your feedback but at the end is our call to decide what to ship to hundreds of thousands of users. So, no I can’t say this way of reasoning is always true.
Right now in Bear, at the database level, a note (N1) tagged #a/b is “owned” by the tag #a and the tag #a/b.
This means that if you ask all the notes of tag #a you get N1 and if you ask all the notes #a/b you get N1.
My understanding is you want the list of notes of tag #a to not include N1
In your scenario, if the user wants to be part of #a should explicitly write #a inside the note text.
Please notice here I’m not mentioning “hide-subtags”, this is the data representation in the database and implies changes in the app behaviors regardless of data visualization options (so for all the users).
I am not sure if there is a misunderstanding.
Let’s assume note N1 JUST contains #a/b and tag #a is choosen in tag tree from left sidebar. My expectation is: N1 is included in notes list for #aif “hide subtags” is disabled. And it is excluded if “hide subtags” is enabled. So far, so good. I think at that point we can agree?
Just if “hide subtags” is enabled. If it is not enabled i expect and wish N1 to be listed. That is the standard view of bear 1 which i consider perfekt, good and useful in many scenarios.
My point:
I am talking about a note, let it call N2, that contain both tags: #a/b AND#a.
If “hide subtags” is disabled everything is how expected. I think until here we agree.
If now “hide subtags” is enabled i wish N2 to be listed if #a is choosen in tag tree although it N2 has #a/b. Why? Because the note N2 also has #a. What i consider as weird and unexpected behaviour can only occur if there are multiple tags from the same family (f.e #father and #father/son and #father/son/grandson).
Yes sure, but that is my point: i want a note with #a to be shown for #a, but it is not shown if additionally to that tag another subtag from the same family is shown. My argument is: Everyone expects - if he choose a tag in tag tree - that all notes with that tag are shown. therefore i believe that you won’t break the expectations of users. I even ask myself how would you break it? Take a look into the posts of eleanor and gnome.irdian, they would expect the same, they just don’t care
If there are no multiple tags from same family everything for everyone follows all expectations. The issue i am talking about is that i cannot imagine at all that it can be an expectation from any user to click on #a and not to expect that all notes containing that tag #a. What kind of search scenario that would be? Why should someone do that? Actually it is a natural expectation: i click on a tag in the tag tree and expect that all notes are shown that have this tag, never mind if “hide subtags” is enabled or disabled. If it is enabled i expect that all notes are hidden/excluded if the choosen tag doesn’t appear in the note, regardless of subtags.
And once again: the videos i linked give a hint with shown weird and unexpected behaviour
I do understand that’s what you want but I’m trying to explain why we can’t.
In the scenario I mentioned, on Bear’s database, N1 has both #a and #a/b tags regardless of what tags appear inside the note (can be either #a/b or #a #a/b). When we apply the hide subtags filter we can’t scan the note text (too slow) and we should base our reasoning on what we have on the database. What we have doesn’t allow us to distinguish between N1 and a note containing #a #a/b in its text.
What you want can be done by changing how subtags work: N1 has just the tag #a/b on the database. But this will drastically change how subtags work for anybody, not just the people using hide subtags.
What you propose also breaks some other user expectations I mentioned before, but It’s pretty clear we don’t agree here and the technical reasons are more relevant.
In my eyes it is hard to communicate that i click on a tag in the tag tree and some notes that contain exactly this tag are not listed. Why would an user not expect to see these notes?
) would be better for what i want to have. Take that as a feature request 
